From exim@www1.ietf.org Fri Aug 1 15: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 PAA07073 for ; Fri, 1 Aug 2003 15: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 19ifaN-00018s-Tj for mmusic-archive@odin.ietf.org; Fri, 01 Aug 2003 15:29:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h71JT7lR004375 for mmusic-archive@odin.ietf.org; Fri, 1 Aug 2003 15: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 19ifaN-00018U-Ov for mmusic-web-archive@optimus.ietf.org; Fri, 01 Aug 2003 15: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 PAA06928 for ; Fri, 1 Aug 2003 15:29:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ifaM-0005Rt-00 for mmusic-web-archive@ietf.org; Fri, 01 Aug 2003 15:29:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ifaL-0005Rp-00 for mmusic-web-archive@ietf.org; Fri, 01 Aug 2003 15: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 19ifaM-00018A-BZ; Fri, 01 Aug 2003 15:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ifa3-0000ru-PY for mmusic@optimus.ietf.org; Fri, 01 Aug 2003 15:28: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 PAA06855; Fri, 1 Aug 2003 15:28:44 -0400 (EDT) Message-Id: <200308011928.PAA06855@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 01 Aug 2003 15:28:44 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-08.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-08.txt Pages : 16 Date : 2003-8-1 This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-08.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-8-1153737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-1153737.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Aug 3 18: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 SAA29248 for ; Sun, 3 Aug 2003 18: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 19jR87-0000RY-QQ for mmusic-archive@odin.ietf.org; Sun, 03 Aug 2003 18:15:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h73MF7gY001698 for mmusic-archive@odin.ietf.org; Sun, 3 Aug 2003 18:15:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jR87-0000RJ-LT for mmusic-web-archive@optimus.ietf.org; Sun, 03 Aug 2003 18: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 SAA29201 for ; Sun, 3 Aug 2003 18:15:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jR84-0004Cl-00 for mmusic-web-archive@ietf.org; Sun, 03 Aug 2003 18:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jR84-0004Ch-00 for mmusic-web-archive@ietf.org; Sun, 03 Aug 2003 18:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jR80-0000Qv-Vc; Sun, 03 Aug 2003 18:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jR7z-0000Qe-Gb for mmusic@optimus.ietf.org; Sun, 03 Aug 2003 18:14:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29186 for ; Sun, 3 Aug 2003 18:14:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jR7w-0004Ce-00 for mmusic@ietf.org; Sun, 03 Aug 2003 18:14:56 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 19jR7v-0004Cb-00 for mmusic@ietf.org; Sun, 03 Aug 2003 18:14:56 -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 h73MDZ7V042746 for ; Sun, 3 Aug 2003 15:14:50 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.9/Submit) id h73MDZrj042745; Sun, 3 Aug 2003 15:13:35 -0700 (PDT) (envelope-from rsf) Message-Id: <4.3.1.1.20030803150631.00b74730@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 03 Aug 2003 15:11:12 -0700 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Minor bug in draft-ietf-mmusic-rfc2326bis-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: , Section 3.2 of "draft-ietf-mmusic-rfc2326bis-04.txt" (the latest RTSP spec) notes that the "host" part of a RTSP URL is "As defined by RFC 2732". However, RFC 2732 is "Format for Literal IPv6 Addresses in URL's", which probably isn't really what you want here (or, at least, is only part of what you want...) Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 13:59: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 SMTP id NAA05688 for ; Mon, 4 Aug 2003 13:59: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 19jjbr-0007QJ-W2 for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 13:59:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Hx3sG028529 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 13:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjbr-0007Pz-RY for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 13:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05649 for ; Mon, 4 Aug 2003 13:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjbp-0004ML-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 13:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jjbo-0004MI-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 13:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjbp-0007O6-Sp; Mon, 04 Aug 2003 13:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjbZ-0007MK-1X for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 13:58:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05640; Mon, 4 Aug 2003 13:58:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjbW-0004M2-00; Mon, 04 Aug 2003 13:58:42 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19jjbV-0004Lt-00; Mon, 04 Aug 2003 13:58:41 -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 NAA21733; Mon, 4 Aug 2003 13:58:02 -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 NAA05995; Mon, 4 Aug 2003 13:58:04 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 13:58:03 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5CB3@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Aaron Falk'" , Jonathan Rosenberg Cc: "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 4 Aug 2003 13:58:01 -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: , > So, is the right thing to do to ramp up at the beginning of the call > to the best rate you can get, then only ramp down? This overcomes > Tom's concerns about probing bandwidth. There is no point in "ramping". You send at the rate you decide (however you decide). If you have to change, you signal a change, disrupt the flow, and change. There isn't anything elastic here. You send at a fixed rate. If you don't recieve at the correct rate you can handle a (small) amount of variation by buffering, but mostly, you discard and hope it gets better. Brian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 14:10: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 SMTP id OAA06137 for ; Mon, 4 Aug 2003 14:10: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 19jjmV-0008JD-KL for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 14:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74IA3r6031933 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 14:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjmV-0008Iy-Fc for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06118 for ; Mon, 4 Aug 2003 14:09:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjmR-0004Re-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:09:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jjmR-0004Rb-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:09:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjmS-0008GH-TV; Mon, 04 Aug 2003 14:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jjle-0008B9-TC for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 14:09:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06054; Mon, 4 Aug 2003 14:09:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjlc-0004R5-00; Mon, 04 Aug 2003 14:09:08 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19jjlb-0004Qh-00; Mon, 04 Aug 2003 14:09:07 -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 h74I8TPV026766; Mon, 4 Aug 2003 14:08:35 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Mon, 4 Aug 2003 14:08:26 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 14:08:26 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB4BB@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Rosen, Brian'" , "'Aaron Falk'" , Jonathan Rosenberg Cc: "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 4 Aug 2003 14:08:24 -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 Brian > > So, is the right thing to do to ramp up at the beginning of the call > > to the best rate you can get, then only ramp down? This overcomes > > Tom's concerns about probing bandwidth. > There is no point in "ramping". You send at the rate you decide > (however you decide). If you have to change, you signal a change, > disrupt the flow, and change. There isn't anything elastic here. > You send at a fixed rate. If you don't recieve at the correct > rate you can handle a (small) amount of variation by buffering, but > mostly, you discard and hope it gets better. Unfortunately, with slow-start, you can't just start sending at an adequate rate. At the beginning of the connection you need to treat the rate that TFRC sets differently from the way you treat it later, after you've slow-started up to an adequate rate. I think that's what Aaron was referring to. Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 14:53: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 SMTP id OAA07639 for ; Mon, 4 Aug 2003 14:53: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 19jkS9-0001Rx-Ph for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 14:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Ir5rV005572 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 14: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 19jkS9-0001Rn-MA for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07578 for ; Mon, 4 Aug 2003 14:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkS6-0004sJ-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkS5-0004sD-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14: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 19jkS5-0001PH-FM; Mon, 04 Aug 2003 14: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 19jkCI-0000dB-N7 for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 14:36:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07171; Mon, 4 Aug 2003 14:36:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkCE-0004kd-00; Mon, 04 Aug 2003 14:36:38 -0400 Received: from eve.cs.ucl.ac.uk ([128.16.64.243]) by ietf-mx with esmtp (Exim 4.12) id 19jkCD-0004ka-00; Mon, 04 Aug 2003 14:36:37 -0400 Received: from eve.cs.ucl.ac.uk (localhost [127.0.0.1]) by eve.cs.ucl.ac.uk (8.12.9/8.12.2) with ESMTP id h74IaANt010656; Mon, 4 Aug 2003 19:36:10 +0100 (BST) From: Mark Handley X-Organisation: UCL To: "Phelan, Tom" cc: "'Rosen, Brian'" , "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC In-reply-to: Your message of "Mon, 04 Aug 2003 14:08:24 EDT." <4CF48720B6E9D4118D040060CF2074E9082BB4BB@sonusdc3.sonusnet.com> Date: Mon, 04 Aug 2003 19:36:10 +0100 Message-ID: <10655.1060022170@eve.cs.ucl.ac.uk> Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >> > So, is the right thing to do to ramp up at the beginning of the call >> > to the best rate you can get, then only ramp down? This overcomes >> > Tom's concerns about probing bandwidth. >> There is no point in "ramping". You send at the rate you decide >> (however you decide). If you have to change, you signal a change, >> disrupt the flow, and change. There isn't anything elastic here. >> You send at a fixed rate. If you don't recieve at the correct >> rate you can handle a (small) amount of variation by buffering, but >> mostly, you discard and hope it gets better. > >Unfortunately, with slow-start, you can't just start sending at an adequate >rate. At the beginning of the connection you need to treat the rate that >TFRC sets differently from the way you treat it later, after you've >slow-started up to an adequate rate. I think that's what Aaron was >referring to. For VoIP, perhaps slowstart at startup is simply unnecessary. Lets look at what TCP does. Assume a 1500 byte MSS, and 200ms RTT. Thus the starting rate for a TCP connection will be one packet/RTT, which is 1500*8/0.2 = 60Kb/s. And this is assuming an initial window of one packet, which is pretty conservative these days. So, a VoIP flow that started at anything up to 64Kb/s (including headers) would be perfectly reasonable - it's no worse than TCP's default behaviour. If the RTT were a lot larger, you'd be expected to start slower, but if it's a lot larger than 200ms, then you're going to have interactivity problems anyway. Now, the question would be what happens when this is too fast? There are two cases really: - Low stat mux at bottleneck. Here TFRC will probably build a queue pretty rapidly, and a good TFRC implementation would slow down as a result of the RTT increasing. Pretty soon you'll see some loss, and things will settle down to the slower steady state. - High stat mux at bottleneck. TFRC won't immediately slow down - that will take some loss to achieve. But the high level of stat muxing and the fact that each flow only sends too fast for a small fraction of it's duration mean that the overall effect should be relatively benign. Thus neither case seems to be terribly bad. But this only applies to VoIP, where the bitrates are relatively benign compared to TCP's startup behaviour, and even then if the RTT is high, you get to start more slowly. Cheers, Mark _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 14:53: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 SMTP id OAA07640 for ; Mon, 4 Aug 2003 14:53: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 19jkS9-0001SI-UQ for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 14:53:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Ir526005588 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 14: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 19jkS9-0001S3-Qt for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07577 for ; Mon, 4 Aug 2003 14:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkS6-0004sG-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkS4-0004sC-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:53:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jkS4-0001Ot-Rv; Mon, 04 Aug 2003 14: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 19jjRK-00078S-N8 for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 13:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05317; Mon, 4 Aug 2003 13:48:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjRI-0004HO-00; Mon, 04 Aug 2003 13:48:08 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19jjRH-0004HK-00; Mon, 04 Aug 2003 13:48:07 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id h74Hm16e007111; Mon, 4 Aug 2003 10:48:01 -0700 Received: (from falk@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id h74HlvAg007110; Mon, 4 Aug 2003 10:47:57 -0700 Date: Mon, 4 Aug 2003 10:47:57 -0700 From: Aaron Falk To: Jonathan Rosenberg Cc: "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Message-ID: <20030804174757.GC23098@isi.edu> Mail-Followup-To: Jonathan Rosenberg , "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" References: <4CF48720B6E9D4118D040060CF2074E9082BB491@sonusdc3.sonusnet.com> <3F260834.5090700@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F260834.5090700@dynamicsoft.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jonathan Rosenberg wrote: > > 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. Jonathan- Looking down the road, do you think that rate adaption is a reasonable thing to expect of future VoIP phones? I.e., I'd like to understand if the design is being influenced by technology limitations which will reasonably go away. > 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. This seems a point less likely to go away. Perhaps this is (one reason) why rate adaption isn't in current phones. So, is the right thing to do to ramp up at the beginning of the call to the best rate you can get, then only ramp down? This overcomes Tom's concerns about probing bandwidth. --aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 15:41: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 SMTP id OAA07642 for ; Mon, 4 Aug 2003 14:53: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 19jkSA-0001SZ-2F for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 14:53:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Ir60h005608 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 14: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 19jkS9-0001SJ-VK for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 14:53:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07583 for ; Mon, 4 Aug 2003 14:53:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jkS6-0004sN-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jkS5-0004sK-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 14: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 19jkS5-0001P5-5D; Mon, 04 Aug 2003 14: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 19jjrc-00007i-Ur for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 14:15:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06429; Mon, 4 Aug 2003 14:15:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jjra-0004Xr-00; Mon, 04 Aug 2003 14:15:18 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19jjrZ-0004Xm-00; Mon, 04 Aug 2003 14:15:17 -0400 Received: from nit.isi.edu (loopback [127.0.0.1]) by nit.isi.edu (8.12.8/8.12.8) with ESMTP id h74IF96e007269; Mon, 4 Aug 2003 11:15:09 -0700 Received: (from falk@localhost) by nit.isi.edu (8.12.8/8.12.8/Submit) id h74IF9AQ007268; Mon, 4 Aug 2003 11:15:09 -0700 Date: Mon, 4 Aug 2003 11:15:09 -0700 From: Aaron Falk To: "Rosen, Brian" Cc: Jonathan Rosenberg , "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Message-ID: <20030804181508.GG23098@isi.edu> Mail-Followup-To: "Rosen, Brian" , Jonathan Rosenberg , "Phelan, Tom" , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" References: <313680C9A886D511A06000204840E1CF070B5CB3@whq-msgusr-02.pit.comms.marconi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <313680C9A886D511A06000204840E1CF070B5CB3@whq-msgusr-02.pit.comms.marconi.com> User-Agent: Mutt/1.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Rosen, Brian wrote: > > > > So, is the right thing to do to ramp up at the beginning of the call > > to the best rate you can get, then only ramp down? This overcomes > > Tom's concerns about probing bandwidth. > > There is no point in "ramping". You send at the rate you decide > (however you decide). If you have to change, you signal a change, > disrupt the flow, and change. There isn't anything elastic here. > You send at a fixed rate. If you don't recieve at the correct > rate you can handle a (small) amount of variation by buffering, but > mostly, you discard and hope it gets better. Brian- I'm concerned about the effect "sending at a fixed rate" might have on other traffic in the network. "Ramping", or slow start, at the beginning of the call allows the sender to probe for the available capacity. Otherwise, how does the sender know what rate to start sending at? If he starts too high, he'll blow away a bunch of TCP flows while he figures out his loss rate is too high. Starting too low will result in the minimal quality to users. Am I missing something here? I do agree that, since codecs output rates are quantized, ramping down really means jumping from one to the next lower rate. --aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 16: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 SMTP id QAA11349 for ; Mon, 4 Aug 2003 16: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 19jm4o-0004QF-PV for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 16:37:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74Kb6oV016989 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 16: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 19jm4o-0004Pw-Ke for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 16: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 SMTP id QAA11343 for ; Mon, 4 Aug 2003 16:37:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jm4m-0005Se-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 16:37:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jm4m-0005Sb-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 16:37:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jm4j-0004Nx-Sa; Mon, 04 Aug 2003 16: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 19jklw-0002Ul-3N for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 15:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09406 for ; Mon, 4 Aug 2003 15:13:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jklu-00057h-00 for mmusic@ietf.org; Mon, 04 Aug 2003 15:13:30 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19jklt-00057e-00 for mmusic@ietf.org; Mon, 04 Aug 2003 15:13:29 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h74JDQe3028206; Mon, 4 Aug 2003 12:13:26 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200308041913.h74JDQe3028206@cougar.icir.org> To: Mark Handley cc: "'Rosen, Brian'" , "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" From: Sally Floyd Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 04 Aug 2003 12:13:26 -0700 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >For VoIP, perhaps slowstart at startup is simply unnecessary. Lets >look at what TCP does. Assume a 1500 byte MSS, and 200ms RTT. Thus >the starting rate for a TCP connection will be one packet/RTT, which >is 1500*8/0.2 = 60Kb/s. And this is assuming an initial window of one >packet, which is pretty conservative these days. Initial windows: The current standard for TCP, RFC 3390 on Increasing TCP's Initial Window (Proposed Standard), permits an initial window of min (4*MSS, max (2*MSS, 4380 bytes)) bytes. That is, at least two MSS, and up to four MSS, up to an initial window of 4380 bytes. TCP Initial windows of two packets are not uncommon, and initial windows of three or four packets can occasionally be observed. ("http://www.icir.org/tbit/June2003/initwin.512.txt"). The question on the table seems to be whether RFC 3390 could be adapted for low-rate VoIP flows using DCCP to allow initial windows of 4380 bytes regardless of packet size. It certainly seems reasonable to me. (I am agreeing with Mark's previous email on this.) If the congested link is a low-bandwidth one, then the limitation is in bytes per second rather than packets per second, and 4380 bytes in small, spaced-out packets would be less of a load than 4380 bytes in 2-4 larger packets. If the congested link is a high-bandwidth one, and the limitation is in bytes per second, then the argument above still holds. If the congested link is a high-bandwidth one and the limitation is in packets per second, then it is still the case that the VoIP flows would be pacing their packets out, which would limit the damage they would do if 4380 bytes was too high for the allowed sending rate. So it strikes me as liveable, for a rate-limited, low-bandwidth, long-lifetime app like VoIP, to resume with sending rates up to 4380 bytes per RTT after a quiescent period. Quiescent periods: The question then would be whether best-effort VoIP could, after a long quiescient period, resume sending with a sending rate of up to 4380 bytes per RTT (assuming that it got to send at least that much before the quiescent period). Again, this seems plausible to me, for the reasons that Mark described (though it would of course have to be looked at a bit more). And the diatribe about best-effort service: I can't imagine a viable justification for a best-effort flow to resume sending at a sending rate significantly higher than 4380 bytes per RTT after a long idle period. My own assumption is that there are certain rules that go along with best-effort traffic, and one of them is that you don't trash competing TCP traffic. Flows that have strict requirements for QoS probably aren't going to get their needs met with best-effort service with or without DCCP or other forms of congestion control. - Sally http://www.icir.org/floyd/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 4 17:28: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 SMTP id RAA12484 for ; Mon, 4 Aug 2003 17:28: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 19jmsE-00063J-2u for mmusic-archive@odin.ietf.org; Mon, 04 Aug 2003 17:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74LSAqX023264 for mmusic-archive@odin.ietf.org; Mon, 4 Aug 2003 17:28:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmsD-000634-Sv for mmusic-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 17:28:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12450 for ; Mon, 4 Aug 2003 17:28:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmYi-0005e6-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 17:08:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jmYh-0005e3-00 for mmusic-web-archive@ietf.org; Mon, 04 Aug 2003 17:07:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmYj-0005gA-5C; Mon, 04 Aug 2003 17: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 19jmYL-0005bc-Jq for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 17:07:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12140; Mon, 4 Aug 2003 17:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmYJ-0005dq-00; Mon, 04 Aug 2003 17:07:35 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19jmYI-0005dk-00; Mon, 04 Aug 2003 17:07:34 -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 RAA27937; Mon, 4 Aug 2003 17:07:01 -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 RAA00411; Mon, 4 Aug 2003 17:07:03 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Aug 2003 17:07:02 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5CB6@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Sally Floyd'" , Mark Handley Cc: "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 4 Aug 2003 17:06:59 -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: , Two comments: All of these calculations break if it's video rather than audio. We need reasonable rules for video also. The same problems occur, although some video algorithms are not constant data rate. Also > Quiescent periods: > > The question then would be whether best-effort VoIP could, > after a long > quiescient period, resume sending with a sending rate of up > to 4380 bytes > per RTT (assuming that it got to send at least that much before > the quiescent period). Again, this seems plausible to me, for the > reasons that Mark described (though it would of course have to be > looked at a bit more). This of course says that it's all right to do it. I simply want to point out to those not familiar that this can happen. Most audio codecs employ Voice Activity Detection. They don't send compressed data when no one is talking. Incidentally, they do play locally sourced "comfort noise" to the receiver because it turns out to be disconcerting to hear real silence. Some codecs send periodic messages indicating silence should continue (sort of a keep-alive), but they are small, and spaced out. There are several circumstances (a large conference for example), where it is normal to not have anything said in one direction for a very long time. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 5 05:11: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 SMTP id FAA05733 for ; Tue, 5 Aug 2003 05:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqS-00007d-FV for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 05:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h759B4PO000457 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 05:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqS-00007H-AZ for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 05:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05716 for ; Tue, 5 Aug 2003 05:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jxqO-0000g0-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 05:11:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jxqO-0000ft-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 05:11:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqP-00006a-8y; Tue, 05 Aug 2003 05: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 19jpVf-0001j4-Ac for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 20: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 SMTP id UAA16089; Mon, 4 Aug 2003 20:16:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jpVd-0006Qg-00; Mon, 04 Aug 2003 20:17:01 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19jpVc-0006QV-00; Mon, 04 Aug 2003 20:17:00 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h750Gte3034020; Mon, 4 Aug 2003 17:16:56 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200308050016.h750Gte3034020@cougar.icir.org> To: "Rosen, Brian" cc: "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" From: Sally Floyd Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 04 Aug 2003 17:16:55 -0700 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >There are >several circumstances (a large conference for example), where it >is normal to not have anything said in one direction for a very >long time. Yep. For an illustration of this, you could see Section 4.1 on "Lessons from audio traffic" from the following: Comments on Measurement-based Admissions Control for Controlled-Load Services. Floyd, S., Technical Report, July 1996. URL "http://www.icir.org/floyd/papers.html". - Sally _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 5 05: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 SMTP id FAA05734 for ; Tue, 5 Aug 2003 05:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqS-00007m-Gq for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 05:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h759B4vb000469 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 05:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqS-00007I-C0 for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 05:11:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05717 for ; Tue, 5 Aug 2003 05:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jxqO-0000g1-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 05:11:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jxqO-0000fs-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 05:11:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jxqO-00006O-Ur; Tue, 05 Aug 2003 05:11:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jmAv-0004mD-Sa for mmusic@optimus.ietf.org; Mon, 04 Aug 2003 16:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11412; Mon, 4 Aug 2003 16:43:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jmAt-0005TP-00; Mon, 04 Aug 2003 16:43:23 -0400 Received: from cougar.icir.org ([192.150.187.76]) by ietf-mx with esmtp (Exim 4.12) id 19jmAt-0005TM-00; Mon, 04 Aug 2003 16:43:23 -0400 Received: from cougar.icir.org (localhost [127.0.0.1]) by cougar.icir.org (8.12.8p1/8.12.3) with ESMTP id h74KhHe3029296; Mon, 4 Aug 2003 13:43:17 -0700 (PDT) (envelope-from floyd@cougar.icir.org) Message-Id: <200308042043.h74KhHe3029296@cougar.icir.org> To: Jonathan Rosenberg cc: "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" From: Sally Floyd Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Mon, 04 Aug 2003 13:43:17 -0700 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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 - >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. Yep, but the allowed loss rates could also be quite a bit higher with yet a different set of TCP parameters. E.g., for a TCP connection with reasonably fine-grained timestamps, implemented so that a backed-off retransmit timer is reset when a retransmitted packet makes it through and is acked. (This would be perfectly conformant with the standards.) It is on my to-do list to run these simulations, to compare with the simulations in the draft, just to illustrate the range of possible TCP behaviors. For all of the simulations in that draft, a useful validation would be for someone to run experiments with a TCP connection with 100 ms round-trip times, with dummy-net introducing random packet drops with probability p. - Sally http://www.icir.org/floyd/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 5 09:48: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 JAA10915 for ; Tue, 5 Aug 2003 09:48: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 19k2AZ-0007M7-5t for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 09:48:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Dm7YR028267 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 09:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AZ-0007Lq-08 for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 09:48: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 JAA10852 for ; Tue, 5 Aug 2003 09:48:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2AX-00022K-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 09:48:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2AW-00022H-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 09:48:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2AU-0007Ih-57; Tue, 05 Aug 2003 09:48:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k29l-0007Fu-Do for mmusic@optimus.ietf.org; Tue, 05 Aug 2003 09:47: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 JAA10832; Tue, 5 Aug 2003 09:47:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k29j-00021q-00; Tue, 05 Aug 2003 09:47:15 -0400 Received: from mail.sonusnet.com ([208.45.178.33] helo=revere.sonusnet.com) by ietf-mx with esmtp (Exim 4.12) id 19k29i-00021f-00; Tue, 05 Aug 2003 09:47:14 -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 h75DkiPV023439; Tue, 5 Aug 2003 09:46:44 -0400 (EDT) Received: from sonusdc3.sonusnet.com (unverified) by sonusms1.sonusnet.com (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 5 Aug 2003 09:46:38 -0400 Received: by sonusdc3.sonusnet.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Aug 2003 09:46:37 -0400 Message-ID: <4CF48720B6E9D4118D040060CF2074E9082BB4BE@sonusdc3.sonusnet.com> From: "Phelan, Tom" To: "'Rosen, Brian'" , "'Sally Floyd'" , Mark Handley Cc: "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Tue, 5 Aug 2003 09:46:32 -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 Brian, > All of these calculations break if it's video rather than audio. > We need reasonable rules for video also. The same problems > occur, although some video algorithms are not constant data rate. Do we have the same problem that we have with voice? That is, silence suppression reduces the transmit rate to zero for many RTTs. Does "stillness" suppression also reduce the rate to zero? Or is there a minimum rate that's greater than zero? Tom P. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 5 10:28: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 KAA13534 for ; Tue, 5 Aug 2003 10:28: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 19k2nD-0001Mn-PW for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 10:28:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75ES3p0005249 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 10:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k2nD-0001Ma-MV for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 10:28: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 KAA13510 for ; Tue, 5 Aug 2003 10:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2nB-0002QC-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 10:28:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k2nA-0002Q8-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 10: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 19k2nB-0001Kf-QZ; Tue, 05 Aug 2003 10: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 19k2mv-0001HW-Ls for mmusic@optimus.ietf.org; Tue, 05 Aug 2003 10:27: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 KAA13498; Tue, 5 Aug 2003 10:27:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2mt-0002Pu-00; Tue, 05 Aug 2003 10:27:43 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19k2ms-0002Pl-00; Tue, 05 Aug 2003 10:27:42 -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 KAA12148; Tue, 5 Aug 2003 10:27:09 -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 KAA07014; Tue, 5 Aug 2003 10:27:09 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Aug 2003 10:27:09 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5CBB@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Phelan, Tom'" , "'Sally Floyd'" , Mark Handley Cc: "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Tue, 5 Aug 2003 10:27:08 -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: , Generally, there is no "silence". On some algorithms, if you remain REALLY still, the data rate drops very low, but I've never seen zero. Brian > -----Original Message----- > From: Phelan, Tom [mailto:tphelan@sonusnet.com] > Sent: Tuesday, August 05, 2003 9:47 AM > To: 'Rosen, Brian'; 'Sally Floyd'; Mark Handley > Cc: 'Aaron Falk'; Jonathan Rosenberg; 'dccp@ietf.org'; > 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC > > > Hi Brian, > > > All of these calculations break if it's video rather than audio. > > We need reasonable rules for video also. The same problems > > occur, although some video algorithms are not constant data rate. > > Do we have the same problem that we have with voice? That is, silence > suppression reduces the transmit rate to zero for many RTTs. Does > "stillness" suppression also reduce the rate to zero? Or is > there a minimum > rate that's greater than zero? > > Tom P. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 5 11:45: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 LAA16660 for ; Tue, 5 Aug 2003 11:45: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 19k3zn-0004er-0a for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 11:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Fj6l7017889 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 11:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3zm-0004eQ-Qv for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 11:45: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 LAA16631 for ; Tue, 5 Aug 2003 11:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3zl-0003Iy-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 11:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k3zk-0003Iu-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 11:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3zh-0004dk-RL; Tue, 05 Aug 2003 11: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 19k2qv-0001cK-EI for mmusic@optimus.ietf.org; Tue, 05 Aug 2003 10:31: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 KAA13724; Tue, 5 Aug 2003 10:31:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2qs-0002SH-00; Tue, 05 Aug 2003 10:31:51 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19k2qs-0002S2-00; Tue, 05 Aug 2003 10:31: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 KAA12320; Tue, 5 Aug 2003 10:31:17 -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 KAA07737; Tue, 5 Aug 2003 10:31:17 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Aug 2003 10:31:17 -0400 Message-ID: <313680C9A886D511A06000204840E1CF070B5CBC@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Henning Schulzrinne'" , "Phelan, Tom" Cc: "'Sally Floyd'" , Mark Handley , "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: RE: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC Date: Tue, 5 Aug 2003 10:31:17 -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: , Yeah, and this is one of the most difficult scenarios to get to work. You are not sending anything, then all of a sudden, you are sending full rate audio and video. In some codecs, the start of video is an instant peak rate transfer, and if you lose some of it, it causes retries, or really annoying visual results. The audio start is very important; you have to get the audio through, and you don't have anything like a second to get it up. The result of doing it wrong is clipping of the initial utterance, which is really annoying and causes people to get into really weird behavior. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, August 05, 2003 9:51 AM > To: Phelan, Tom > Cc: 'Rosen, Brian'; 'Sally Floyd'; Mark Handley; 'Aaron > Falk'; Jonathan > Rosenberg; 'dccp@ietf.org'; 'mmusic@ietf.org'; Pasco Anderson, Jay > Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC > > > In a conference, it is quite common that video-follows-audio, > i.e., only > the current (and maybe the most recent) speaker sends video. > Thus, the > problem is somewhat similar - when somebody starts speaking, > you want to > immediately have decent-quality video of that speaker. > > Phelan, Tom wrote: > > > Hi Brian, > > > > > >>All of these calculations break if it's video rather than audio. > >>We need reasonable rules for video also. The same problems > >>occur, although some video algorithms are not constant data rate. > > > > > > Do we have the same problem that we have with voice? That > is, silence > > suppression reduces the transmit rate to zero for many RTTs. Does > > "stillness" suppression also reduce the rate to zero? Or > is there a minimum > > rate that's greater than zero? > > > > 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 Tue Aug 5 12: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 LAA16661 for ; Tue, 5 Aug 2003 11:45: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 19k3zn-0004eq-0Q for mmusic-archive@odin.ietf.org; Tue, 05 Aug 2003 11:45:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Fj64a017893 for mmusic-archive@odin.ietf.org; Tue, 5 Aug 2003 11:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3zm-0004eR-Ra for mmusic-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 11:45: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 LAA16628 for ; Tue, 5 Aug 2003 11:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k3zl-0003J1-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 11:45:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k3zk-0003Iv-00 for mmusic-web-archive@ietf.org; Tue, 05 Aug 2003 11:45:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k3zh-0004dX-Dj; Tue, 05 Aug 2003 11: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 19k2Kl-00081m-PZ for mmusic@optimus.ietf.org; Tue, 05 Aug 2003 09:58: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 JAA11234; Tue, 5 Aug 2003 09:58:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k2Kj-000290-00; Tue, 05 Aug 2003 09:58:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19k2Kj-00028x-00; Tue, 05 Aug 2003 09:58:37 -0400 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h75Dohm2025360 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 5 Aug 2003 09:50:46 -0400 (EDT) Message-ID: <3F2FB633.7090509@cs.columbia.edu> Date: Tue, 05 Aug 2003 09:50:43 -0400 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Phelan, Tom" CC: "'Rosen, Brian'" , "'Sally Floyd'" , Mark Handley , "'Aaron Falk'" , Jonathan Rosenberg , "'dccp@ietf.org'" , "'mmusic@ietf.org'" , "Pasco Anderson, Jay" Subject: Re: [dccp] Re: [MMUSIC] Two-way media with DCCP and TFRC References: <4CF48720B6E9D4118D040060CF2074E9082BB4BE@sonusdc3.sonusnet.com> In-Reply-To: <4CF48720B6E9D4118D040060CF2074E9082BB4BE@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 In a conference, it is quite common that video-follows-audio, i.e., only the current (and maybe the most recent) speaker sends video. Thus, the problem is somewhat similar - when somebody starts speaking, you want to immediately have decent-quality video of that speaker. Phelan, Tom wrote: > Hi Brian, > > >>All of these calculations break if it's video rather than audio. >>We need reasonable rules for video also. The same problems >>occur, although some video algorithms are not constant data rate. > > > Do we have the same problem that we have with voice? That is, silence > suppression reduces the transmit rate to zero for many RTTs. Does > "stillness" suppression also reduce the rate to zero? Or is there a minimum > rate that's greater than zero? > > 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 Sat Aug 9 08:00: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 IAA26442 for ; Sat, 9 Aug 2003 08:00: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 19lSOF-0004k3-UC for mmusic-archive@odin.ietf.org; Sat, 09 Aug 2003 08:00:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h79C07mQ018222 for mmusic-archive@odin.ietf.org; Sat, 9 Aug 2003 08:00:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lSOF-0004jp-Pa for mmusic-web-archive@optimus.ietf.org; Sat, 09 Aug 2003 08:00: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 IAA26438 for ; Sat, 9 Aug 2003 08:00:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lSOE-0000q2-00 for mmusic-web-archive@ietf.org; Sat, 09 Aug 2003 08:00:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lSOE-0000py-00 for mmusic-web-archive@ietf.org; Sat, 09 Aug 2003 08:00:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lSO8-0004ip-Ta; Sat, 09 Aug 2003 08:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l7nD-0005Uo-Sc for mmusic@optimus.ietf.org; Fri, 08 Aug 2003 10:00: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 KAA11097 for ; Fri, 8 Aug 2003 10:00:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l7nB-0000sk-00 for mmusic@ietf.org; Fri, 08 Aug 2003 10:00:29 -0400 Received: from mail2.zrz.tu-berlin.de ([130.149.4.14]) by ietf-mx with esmtp (Exim 4.12) id 19l7nB-0000rr-00 for mmusic@ietf.org; Fri, 08 Aug 2003 10:00:29 -0400 Received: from localhost ([127.0.0.1] helo=mail2.zrz.TU-Berlin.DE) by mail2.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l7me-00089g-BV; Fri, 08 Aug 2003 15:59:56 +0200 Received: from mail2.zrz.TU-Berlin.DE ([130.149.4.14]) by mail2.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Fri, 8 Aug 2003 15:59:56 +0200 (CEST) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail2.zrz.tu-berlin.de with esmtp (exim-4.20-2) for id 19l7mb-00080O-CC; Fri, 08 Aug 2003 15:59:53 +0200 Received: from almathea (mail@almathea.tkn.TU-Berlin.DE [130.149.49.56]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id h78DxqC09700 for ; Fri, 8 Aug 2003 15:59:52 +0200 Received: from karl by almathea with local (Exim 3.35 #1 (Debian)) id 19l7ma-0003UD-00 for ; Fri, 08 Aug 2003 15:59:52 +0200 To: mmusic@ietf.org Message-Id: From: Holger Karl Date: Fri, 08 Aug 2003 15:59:52 +0200 X-Virus-Scanned: Sophos MailMonitor on mail2.zrz.tu-berlin.de; Fri, 08 Aug 2003 15:59:54 +0200 Subject: [MMUSIC] Call for Papers: WiOpt'04 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- Note: The submission deadline is 5th of November, 2003. *************************************************** ******** CALL FOR PAPERS ******** *************************************************** * * * WiOpt '04 * * * * 2nd Workshop on Modeling and Optimization * * in Mobile, Ad Hoc and Wireless Networks * * * * March 24 - 26, 2004, Cambridge, UK * * * * * *************************************************** Workshop Website: http://www.cl.cam.ac.uk/Research/SRG/wiopt04/ This workshop is intended to bring together leading researchers from both academia and industry to present both foundations and practical methods and tools for modeling and optimisation of mobile and ad hoc networks. The workshop will bring together researchers studying optimisation issues of mobile networks from both the network performance and the mobile networking perspectives: * Mobile Network Optimisation: Applications and Algorithms * Performance characterisation and optimisation of mobile/wireless networks and systems * Protocol design (MAC, Routing) for optimal mobile network utilisation * Tools for network optimisation * Energy efficiency in mobile networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad hoc networks. Papers to be presented at WiOpt'04 will be selected based on extended abstracts of up to 8 pages, double-spaced, 12 point font size. The submission should not exceed 3000 words including tables and figures, each of which count as 250 words. Authors of accepted presentations will have the opportunity to publish either the extended abstract or the full paper in a proceedings volume. Full papers will further be considered for publication in a special issue of the MONET journal. Plenary Speakers: Bruce Hajek (University of Illinois at Urbana-Champaign, USA) Ian Akyildiz (Georgia Institute of Technology, USA) IMPORTANT DATES: Submission of extended abstract: Nov. 5, 2003. Notification of acceptance: Jan. 15, 2003. Camera ready copy: Feb. 15, 2003. (Further details on the workshop website, http://www.cl.cam.ac.uk/Research/SRG/wiopt04/) General chairman: Imrich Chlamtac Vice General Chair: Roger Whitaker Program Co-Chairs: Marco Conti and Tamer Basar Program committee of the conference: Eitan Altman, Venkat Anantharam, Konstantin Avrachenkov, Andrew Campbell, A. Chockalingam, Jon Crowcroft, Silvia Giordano, Stephen V. Hanly, Jean-Pierre Hubaux, Holger Karl, Peter Key, P. R. Kumar, Peter Marbach, Philippe Nain, Sven Oestring, Yoshikuni Onozato, Ramesh Rao, Ness Shroff, Violet Syrotiuk, Thierry Turletti, Adam Wolisz, Jeff Wieselthier Local Arrangements Co-Chair: Sven Oestring and Julian Chesterfield Publicity Chair: Holger Karl Sponsors: The workshop is co-sponsored by * Univ. of Cambridge * IIT (Istituto di Informatica e Telematica) * Intel * Microsoft * IEEE IT Society (technical co-sponsorship) (ACM sponsorship is pending.) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Aug 10 08:41: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 IAA05018 for ; Sun, 10 Aug 2003 08:41: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 19lpVU-0002un-Hs for mmusic-archive@odin.ietf.org; Sun, 10 Aug 2003 08:41:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ACf8RK011202 for mmusic-archive@odin.ietf.org; Sun, 10 Aug 2003 08:41:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lpVU-0002ub-6k for mmusic-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 08:41:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05015 for ; Sun, 10 Aug 2003 08:41:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lpVS-00079m-00 for mmusic-web-archive@ietf.org; Sun, 10 Aug 2003 08:41:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19lpVS-00079i-00 for mmusic-web-archive@ietf.org; Sun, 10 Aug 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 19lpVN-0002uA-58; Sun, 10 Aug 2003 08: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 19lpVL-0002tw-05 for mmusic@optimus.ietf.org; Sun, 10 Aug 2003 08:40: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 IAA05006 for ; Sun, 10 Aug 2003 08:40:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lpVJ-00079f-00 for mmusic@ietf.org; Sun, 10 Aug 2003 08:40:57 -0400 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 19lpVI-00079c-00 for mmusic@ietf.org; Sun, 10 Aug 2003 08:40:56 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by imh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h7ACehmI018542; Sun, 10 Aug 2003 14:40:43 +0200 (MEST) Message-ID: <3F363DA3.3050200@tzi.uni-bremen.de> Date: Sun, 10 Aug 2003 14:42:11 +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] Draft MMUSIC Minutes from Vienna Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, attached are the draft MMUSIC minutes from our meeting in Vienna. The slides are available at http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-ppt.zip http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-pdf.zip Joerg ------------------------------------------------------------------------ Draft Minutes of the MMUSIC WG Meeting at the 57th IETF ======================================================= Reported by Joerg Ott and Colin Perkins Notes taken by Colin Perkins The MMUSIC WG met once at the 57th IETF. The meeting was chaired by Colin Perkins and Joerg Ott. It was attended by some 90 participants. Status Update ------------- Joerg Ott reported on the status of the working and the general progress since the 56th IETF in San Francisco: - The new charter was finally approved. - RFC 3524 was published on SDP extensions for reservation flows. - Two documents are with the RFC editor: SDP extensions for NAT traversal and SDPng transition. - Two documents are with the IESG, and comments have been received: - draft-rajeshkumar-mmusic-gpmd-03.txt was felt to overlap with work on capability negotiation carried out elsewhere; it was noted that this probably applies to most of SDP except that SDP was first. The chairs and authors will work with the IESG to sort this out. - draft-ietf-mmusic-sdp-new-13.txt received many comments which were discussed in a separate slot (see below). - Two documents are under AD review: - draft-ietf-mmusic-sdp-srcfilter-05.txt - draft-ietf-mmusic-sdp-comedia-05.txt - draft-ietf-mmusic-sdp-bwparam-04.txt is completing WGLC on 28 Jul 2003. - The SDP extensions for key management (draft-ietf-mmusic-kmgmt-ext-07.txt) have been waiting for the MIKEY work to complete which seems to progress. A further revision is expected shortly after the IETF. - The SDP implementation draft draft-ietf-mmusic-sdp-implem-00.txt has not been revised yet, but Tom Taylor is working on it. He is trying to incorporate further implementation experience from inside his company as well as from the SIPit events. Two potential new work items have been discussed for MMUSIC: - Real-time fax (draft-ietf-sipping-realtimefax-01.txt) from the SIPPING WG is to provide implementers with guidelines on how to use registered SDP attributes for ITU-T T.38. This document actually contains two logical parts: the use of offer/answer mechanics (which belongs to MMUSIC) and a discussion of SIP-specific signaling (which belongs to SIPPING). It is suggested to investigate splitting the document to deal with each one in the respective WG. But it was pointed out that this document merely contains examples only and hence should be done as a whole in just one WG. To be resolved. - Interactive connectivity establishment (ICE) also from the SIPPING WG (draft-rosenberg-sipping-ice-01.txt). This is discussed later on the agenda. Revised SDP (draft-ietf-mmusic-sdp-new-13.txt) ---------------------------------------------- Colin Perkins reported on the changes incorporated in the latest revision of SDP: It was attempted to clarify when the k= attribute may be used. Further clarifications include: RTP may be used with non-consecutive port numbers and a=charset is only allowed as a session level attribute. Also, unregistered X- attributes and media format are deprecated. Finally, IANA considerations and references were updated. Colin further reported on issues raised on revision -13 on the mailing list, as well as from the IESG review. - An ABNF inconsistency was found: a comment in the ABNF for "token-char" allowed for a larger set of characters than the actual definition. One could either (1) change the comment to match the actual grammar (and thus reduce the set of allowed characters) or (2) modify the grammar to match the comment. The group agreed to go with option (1), pending a check against the use of SDP in RFC 3108. Tom Taylor volunteered to find this out. - The use of b= with layered coding should be clarified as follows: When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. This was accepted in principle but it was also pointed out that a bandwidth specification per layer would be helpful. Further discussion is needed on the mailing list. - Again with layered coding, it should be clarified which ports are associated with an m= line. The clarification proposal was accepted. - The k= is underspecified. The most straightforward way would be to deprecate the use of this field altogether. Opinions from implementers are sought. It was reported that MS Messenger uses this field; the details are unknown at this moment though. As there are implementation out there, just deprecating this field won't work. Therefore, further work needs to go into the specification of using k=. In particular, when k= shall be used, a secure channel must be available and endpoints need to be sure that no third party can eavesdrop on the key. These issues, however, need to be specified by those using SDP rather than SDP itself. The k= field currently supports an algorithm indicator, but it should also specify a key type. This may be implied by the URI or the media protocol used. For more complex scenarios, e.g. when more than one key is needed, either the sdescriptions work (draft-ietf-mmusic-sdescriptions-01.txt) or the key management (draft-ietf-mmusic-kmgmt-ext-07.txt) work should be used. It was proposed that the security considerations section should change "SHOULD NOT deliver the user into an interactive multimedia session..." to "MUST NOT...". It was found that this is an issue of user authorization (e.g. the user may be able to pre-authorize the automatic joining of certain interactive sessions) and needs to be dealt with by the protocols using SDP. - The suggestion to define a "IN" value for private address spaces was rejected because systems 1) cannot tell whether they are in a private address space (relative to their peers) and 2) this change would be not backward compatible. - It will be clarified that UTF-8 normalization is not needed because comparisons are not done on fields with UTF-8. - Proposal on a=inactive: it was agreed not to change the SDP spec here (this is an issue for users of SDP, which may establish conventions for use, not for SDP itself). - Wording should be added that u= and k= may include URIs that may be dereferenced in some (but not all) cases. Also, it should be noted a k= URI may typically be an http or https URI. Both suggested wording additions were accepted. Colin will fold the comments and the discussion into the document and produce a new revision out within a couple of weeks. SDP Security Descriptions (draft-ietf-mmusic-sdescriptions-01.txt) ------------------------------------------------------------------ Dan Wing briefly reviewed the document and the changes from the previous revision: a new syntax is proposed for the a=crypto attribute and the offer/answer part is revised which may need further review. For the next steps, Colin noted that an IANA considerations section is needed, including a discussion of the registration procedures. Furthermore, reviewers for finishing the document were sought: Tom Taylor, Magnus Westerlund, and Martin Euchner volunteered. Offer/Answer Examples (draft-johnston-mmusic-offer-answer-examples-01.txt) -------------------------------------------------------------------------- Alan Johnston presented the changes to the document: in particular, an example for asymmetric use of a codec has been added. This is to be achieved using two distinct m= lines with the same port number, one indicating "sendonly", the other "recvonly". The proposed behavior caused some discussion: it was felt that the mechanism was underspecified and that (therefore) m= lines with the same port would be a bad idea. Yet, the right approach to achieve the desired behavior seemed unclear. Gonzalo Camarillo pointed out that the RFC3388 provided a similar example, but with an explicit grouping (which is not present in this draft). The applicability of RFC3388 to this problem was discussed further. Orit Levin pointed out that the intention clearly is to use RFC 3388 but the question is what happens to the endpoints that don't support RFC 3388. Gonzalo argued that this is already defined in RFC 3388. The chairs stated that they would like to see the asymmetric codec behavior with two m= line properly specified in a document. The present offer/answer examples draft is meant to be illustrative; the example should be kept in place (with added grouping) but the normative text for this behavior needs to be someplace else. Flemming Andreasen suggested to specify part of this practice in the revised SDP. SDPng Update (draft-ietf-mmusic-sdpng-06.txt) --------------------------------------------- Dirk Kutscher presented the latest progress on SDPng, addressing the open issues from draft -06 (a new revision still needs to be submitted). The SDPng structure has been enhanced to decouple capability negotiation for potential configurations from actual configuration (and the respective session parameters). While the capability model has been kept, the syntax has been revised to exclusively rely on XML mechanisms (rather than embedding own syntax conventions for attributes) -- which is less efficient but much cleaner. Dirk presented the new syntax using several examples and also showed a formal schema definition. A further refinement from draft -06 is to remove the concept of libraries and use inline definitions instead -- so that SDPng documents would be self-contained. There was little discussion. Steve Casner asked whether this work was getting enough traction and questioned whether people were really preparing for a transition. Joerg Ott argued that people are desparately holding onto SDP (which is perceived easier with one small extension at a time) -- but that examples show that this getting more complicated so that SDP is likely to have only a finite lifetime. So it would be nice to get broader review from the community on a replacements for SDP. RTP DoS Attacks (draft-rosenberg-mmusic-rtp-denialofservice-00.txt) Interactive Connectivity Establishment (draft-rosenberg-sipping-ice-01.txt) --------------------------------------------------------------------------- Jonathan Rosenberg introduced the RTP DoS problem: An attacker may easily direct the RTP stream(s) from an unsuspecting source to any target by providing the target's IP address in the SDP. This works for SIP and RTSP -- with RTSP providing limited protection by allowing unicast RTP streams only to the address of the originator (but NATs make it worse as anyone behind the same NAT can easily be attacked). As authentication mechanisms can at most help identify the attacker (which may be very weak though), some kind of handshake mechanism is needed so that sources do not start sending media streams unless they know that the right receiver is actually waiting for it: a request/response mechanism using the RTP ports is needed. This is ICE (see below) which has been chosen as a solution for SIP. However, ICE has broader applicability and may be appropriate for RTSP, too -- which needs to be determined by the group. Jonathan reviewed the properties of the ICE approach and briefly walked through the basic ICE algorithm. With ICE being signaling protocol independent, MMUSIC is asked to take ICE up as a WG item. ICE is felt to introduce quite some complexity for RTSP endpoints. If, however, NAT traversal (which is an RTSP issue on its own, see below) and security can be addressed by the same mechanism, it may be worth the effort. It is noted that even if we go for the ICE mechanism for RTSP right now, this does not solve the problem as long as old RTSP servers are still out there. Regarding the ICE proposal as a WG item Magnus Westerlund argued that if it is accepted, one should split the draft into several parts: the SIP use, the ICE mechanism, the use with offer/answer, etc. There was consensus in the group to accept ICE as new WG item, and to fully document the RTP DoS issues as an informational document. RTSP Update (draft-ietf-mmusic-rc2326bis-04.txt ----------------------------------------------- Magnus Westerlund reported on the progress of the RTSP revision, achieved by having a new co-editor joining the team, many teleconference calls, and also quite some list discussion. He presented a number of changes from draft -03 (see the slides). With this, most known open issues are resolved, with only a few ones remaining (see slides). But many resolutions still need to be folded into an updated revision of the draft. When this is done, a second phase of editing on the spec is needed: examples need to be fixed, the spec's consistency needs to be checked as needs it overall readability, and, potential new open issues need to be solved. With all this, the revised RTSP spec will not meet the October deadline as currently documented in the MMUSIC charter. Magnus suggests another six months would be appropriate to finalize the work. RTSP and NAT (draft-ietf-mmusic-rtsp-nat-01.txt) ------------------------------------------------ Magnus Westerlund introduced the revised draft on RTSP and NATs, the purpose of which is to describe how to traverse NATs and firewalls with RTSP. It documents several possible NAT traversal approaches and gives recommendations regarding RTSP for firewalls. Approaches requiring only modifications on the client side STUN, TURN, and RTP/RTSP tunneled in RTSP. Application-Layer Gateways (ALGs) for RTSP will not require any modifications -- but are generally discouraged. Magnus further discussed open issues, particurlarly the goals for RTSP for NATs (i.e. what type of scenarios should be achievable) as well as possible solutions (symmetric RTP, STUN, ICE, DCCP). On the ALGs: The group generally agreed that ALGs are a bad thing and should not be considered further (except for documentation purposes and to communicate this clearly to outside the IETF -- and fast, as people start deploying these). On the document's purpose: Commenters state that, currently, the draft does not give conclusive resolution of what to do as an implementer, it is merely an inventory. It is proposed to pick some solution and write it up, e.g. in the RTSP spec. Magnus wants to resolve the structure of the document and then settle on a solution: one for the server and one or more for the client side. Jonathan Rosenberg and Tom Marshal argue over the number of client-side solutions to be documented: Jonathan wants only one while Tom prefers to have multiple feasible solutions document. In case multiple ones are documented, Jonathan wants exactly one "MUST implement" solution to ensure interoperability. There was some further discussion on technical aspects of possible solutions, but no real conclusions were reached. Internet Media Guides (IMG) --------------------------- draft-nomura-mmusic-img-requirements-01.txt draft-nomura-mmusic-img-framework-01.txt After a brief introduction by Joerg Ott, Rod Walsh presented the progress on the IMG requirements document (which will be re-submitted as WG draft by end of August). He briefly reviewed the general topology and IMG distribution aspects and then went through the requirement categories identified in the draft: IMG description requirements and IMG transport requirements. The former primarily address IMG envelopes for existing meta-data formats, the latter their distribution in unicast and multicast, pull and push style scenarios. For multicast push, SAPv2 is probably inadequate, so a successor is sought, e.g. ALC from the RMT WG. It is pointed that additions to ALC need to be specified separately; while Rod wants to use the RMT proposal FLUTE, Lorenzo argues that this may not be 100% appropriate here; Lorenzo also points out that possible tasks in the RMT WG need to happen quickly as the group is trying to wrap up. For unicasting, client-initiated actions could use HTTP while notifications from the server could use SIP mechanims. Rod discusses on the scalability requirements IMG transport and presents a conceptual overview showing the different pieces of an IMG framework and outlines the achieved flexibility. He also addresses data relationships and particularly security considerations as taken into account in the requirements draft. Rod finally discusses the way ahead: the requirements draft is pretty close to finalization; the remaining efforts are mainly editorial and consolidation. The aim is to go for WGLC soon. He also points to the existing framework draft that will be revised by the end of August. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 11 13:28: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 NAA24852 for ; Mon, 11 Aug 2003 13:28: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 19mGSi-00057F-JB for mmusic-archive@odin.ietf.org; Mon, 11 Aug 2003 13:28:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BHS4BS019661 for mmusic-archive@odin.ietf.org; Mon, 11 Aug 2003 13:28:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mGSi-000572-G0 for mmusic-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 13: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 NAA24844 for ; Mon, 11 Aug 2003 13:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGSg-0007hp-00 for mmusic-web-archive@ietf.org; Mon, 11 Aug 2003 13:28:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mGSf-0007hl-00 for mmusic-web-archive@ietf.org; Mon, 11 Aug 2003 13: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 19mGSf-00056d-BS; Mon, 11 Aug 2003 13: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 19mGS4-00054a-5T for mmusic@optimus.ietf.org; Mon, 11 Aug 2003 13:27: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 NAA24812 for ; Mon, 11 Aug 2003 13:27:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mGS2-0007hV-00 for mmusic@ietf.org; Mon, 11 Aug 2003 13:27:22 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19mGS1-0007hH-00 for mmusic@ietf.org; Mon, 11 Aug 2003 13:27:21 -0400 Received: from alor ([130.209.247.84]:49878 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19mGRW-00018y-00 for mmusic@ietf.org; Mon, 11 Aug 2003 18:26:50 +0100 Date: Mon, 11 Aug 2003 18:26:49 +0100 Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-08.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Colin Perkins To: mmusic@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <200308011928.PAA06855@ietf.org> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Friday, Aug 1, 2003, at 20:28 Europe/London, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control > Working Group of the IETF. > > Title : Key Management Extensions for Session Description > Protocol (SDP) and Real Time Streaming > Protocol (RTSP) > Author(s) : J. Arkko et al. > Filename : draft-ietf-mmusic-kmgmt-ext-08.txt > Pages : 16 > Date : 2003-8-1 > > This document defines general extensions for SDP and RTSP to carry > the security information needed by a key management protocol, in > order to secure the media. These extensions are presented as a > framework, to be used by one or more key management protocols. As > such, its use is meaningful only when it is completed by the key > management protocol in use. > General guidelines are also given on how the framework should be used > together with SIP and RTSP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-08.txt I have a number of comments on this draft: - The ABNF in Sections 2.1 and 2.2 is contradictory. The key management data is defined as "text" in one section, and "quoted-string" in the other, yet these two types have different ranges of valid characters (and both are more liberal than the explanatory text, which implies that only base-64 encoded data is allowed). Similar for the protocol identifier: the definitions of "non-ws-string" in SDPnew and "token" in RTSP are not consistent. - It should be stated that the protocol identifiers in Section 2.1 and Section 2.2 refer to the same set of values, and a reference to the registry of legal values should be given (i.e. reference the IANA parameter registry defined in Section 6). - The draft repeatedly mentions Kerberos, and indicates that Kerberos tickets may be included in key management messages, but does not specify how this is to be achieved. Should either specify how to use Kerberos, or remove all references to it. - The second bullet point on Page 6 mentions that other parameters may need to be specified for certain key management protocols, but does not specify how an implementor knows if a particular key management protocol uses additional parameters. Suggest this is listed as part of the IANA registration for a particular key management protocol? - Section 3.1 seems to assume Offer/Answer usage. It is not clear how it applies to SDP used with, for example, SAP, HTTP, or email? What about one-to-many distribution of SDP? Or distributions where there is no back-channel? It is acceptable for the draft to be explicit about the limits of its scope, but it cannot ignore the wider problem space. - The discussion of authentication on Page 7 is not mentioned in the list of things senders and receivers of SDP must do, on pages 5 and 6. - Section 3.3 does not mention authentication. Should I assume that there is no need for authentication when key management is used with RTSP? - Section 4 needs to provide strict guidance about the parameters and specifications needed for new key management protocols. The interface between the key management protocol and this framework should be made explicit. - I find the arguments about security of the SDP in Section 5 weak. The draft needs to be explicit about the threats it prevents and those it leaves open. Recommend re-reading RFC 3553, Section 5. - In section 5, how is a beat-down attack prevented when the attacker wishes to beat-down to no security? What is the correct response to an answer which suggests no security? - Section 6 needs to register the RTSP extensions needed, and make it clear that the namespace for key management protocol identifiers is shared between the RTSP and SDP extensions. - Section 6 mentions that new key management protocols specify "the syntax of possible additional arguments", yet this contradicts the ABNF which states that only a single argument is present. The main issue behind these seems to be the desire to define new parameters which can be left open for future uses. As was mentioned in the context of the "a=gpmd:" attribute, this is not acceptable: there needs to be a precise definition of the semantics of any new SDP attribute/RTSP header before the draft can advance. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Aug 13 16:28: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 QAA04786 for ; Wed, 13 Aug 2003 16:28: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 19n2E1-00062e-AD for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKS5xr023225 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16: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 19n2E1-00062W-4F for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 16:28: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 QAA04771 for ; Wed, 13 Aug 2003 16:28:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2Dz-0004o7-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2Dy-0004o3-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:28:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2Dx-000627-Gr; Wed, 13 Aug 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 19mwuG-0001kO-3i for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 10:47: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 KAA22372 for ; Wed, 13 Aug 2003 10:47:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mwuD-00027S-00 for mmusic@ietf.org; Wed, 13 Aug 2003 10:47:17 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 19mwuC-00027P-00 for mmusic@ietf.org; Wed, 13 Aug 2003 10:47:17 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7DElAeE024898 for ; Wed, 13 Aug 2003 10:47:10 -0400 (EDT) Received: from cof110avexu2.global.avaya.com (h135-9-6-17.avaya.com [135.9.6.17]) by tiere.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7DEl8eE024858 for ; Wed, 13 Aug 2003 10:47:09 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C361A9.C9190967" Date: Wed, 13 Aug 2003 08:47:14 -0600 Message-ID: Thread-Index: AcNhqcnSVlggtgivQmeIcOnM5pEd2A== From: "Raman, Sundereshwaran (Sundereshwaran)" To: Subject: [MMUSIC] (no subject) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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_01C361A9.C9190967 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have question related to dynamic payloads. If a session is estblished = with a dynamic payload type number mapped to a particular codec, can the = number change for the same codec in subsequent offers/answers in the = same session? e.g. Lets say a session was established with a dynamic = payload type number 96 mapped to telephone-event. Now if a new Re-Invite = is sent out, can the response have a different payload type number for = the telephone event? Thanks Sundi ------_=_NextPart_001_01C361A9.C9190967 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have question related to dynamic = payloads. If a session is estblished with a dynamic payload type number = mapped to a particular codec, can the number change for the same codec = in subsequent offers/answers in the same session? e.g. Lets say a = session was established with a dynamic payload type number 96 mapped to = telephone-event. Now if a new Re-Invite is sent out, can the response = have a different payload type number for the telephone event?

Thanks
Sundi


------_=_NextPart_001_01C361A9.C9190967-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Aug 13 16:41: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 QAA05166 for ; Wed, 13 Aug 2003 16:41: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 19n2Qa-0007AZ-Ck for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16:41:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKf4aO027553 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16: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 19n2Qa-0007AK-9E for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 16:41: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 QAA05134 for ; Wed, 13 Aug 2003 16:40:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2QY-0004sT-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:41:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2QX-0004sQ-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2QY-00078Q-6G; Wed, 13 Aug 2003 16: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 19n2Pf-00077b-W2 for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 16: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 QAA05100 for ; Wed, 13 Aug 2003 16:40:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2Pd-0004rx-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:40:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n2Pd-0004ru-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:40:05 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DKdU3m003854; Wed, 13 Aug 2003 16:39:33 -0400 (EDT) Message-ID: <3F3AA1FE.8050800@dynamicsoft.com> Date: Wed, 13 Aug 2003 16:39:26 -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: "Raman, Sundereshwaran (Sundereshwaran)" CC: mmusic@ietf.org Subject: Re: [MMUSIC] (no subject) 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 I believe Section 8.3.2 of RFC 3264 directly answers your question: The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the "m=" line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711. This is true for the answerer as well. Thus, in each direction, once PT number is bound to a codec, that PT number can not be used for a different codec. -Jonathan R. Raman, Sundereshwaran (Sundereshwaran) wrote: > I have question related to dynamic payloads. If a session is estblished > with a dynamic payload type number mapped to a particular codec, can the > number change for the same codec in subsequent offers/answers in the > same session? e.g. Lets say a session was established with a dynamic > payload type number 96 mapped to telephone-event. Now if a new Re-Invite > is sent out, can the response have a different payload type number for > the telephone event? > > Thanks > Sundi > > -- 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 Aug 13 16:51: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 QAA05461 for ; Wed, 13 Aug 2003 16: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 19n2aE-0007Sc-K3 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DKp2QZ028672 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 16: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 19n2aE-0007SN-GS for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 16: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 QAA05454 for ; Wed, 13 Aug 2003 16:50:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2aC-0004wA-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:51:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n2aB-0004w7-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 16:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n2aC-0007Ry-KQ; Wed, 13 Aug 2003 16: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 19n2ZN-0007RA-N4 for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 16:50: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 QAA05418 for ; Wed, 13 Aug 2003 16:50:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2ZL-0004va-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:50:07 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19n2ZK-0004vQ-00 for mmusic@ietf.org; Wed, 13 Aug 2003 16:50:07 -0400 Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 5688284449; Wed, 13 Aug 2003 20:48:53 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by cc26-01.idc1.level3.com (Postfix) with SMTP id 76FA3FBABA; Wed, 13 Aug 2003 20:48:43 +0000 (GMT) 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, 13 Aug 2003 14:48:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] (no subject) Date: Wed, 13 Aug 2003 14:48:42 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013A94C@idc1exc0004.corp.global.level3.com> Thread-Topic: [MMUSIC] (no subject) Thread-Index: AcNh21wTGt9wWOt7TbSQJ3jNw9nVcgAAEe+Q From: "Hearty, John" To: "Jonathan Rosenberg" , "Raman, Sundereshwaran (Sundereshwaran)" Cc: X-OriginalArrivalTime: 13 Aug 2003 20:48:43.0252 (UTC) FILETIME=[48703B40:01C361DC] 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 text calls out the special case of disallowing changing the PT in the case of RTP. The example was for telephone events. I suspect you would risk interop problems if you didn't follow the RTP rule in the text for telephone events, but technically the example is removing the 96 PT and adding a different PT mapping to telephone events which the text seems to allow. The rules are for a particular media stream in the session. It may be safer to use a whole new media stream for the new PT if you really need to do it for some reason. John Hearty Level3 > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, August 13, 2003 2:39 PM > To: Raman, Sundereshwaran (Sundereshwaran) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] (no subject) >=20 > I believe Section 8.3.2 of RFC 3264 directly answers your question: >=20 > The list of media formats used in the session MAY be changed. To do > this, the offerer creates a new media description, with the list of > media formats in the "m=3D" line different from the corresponding media > stream in the previous SDP. This list MAY include new formats, and > MAY remove formats present from the previous SDP. However, in the > case of RTP, the mapping from a particular dynamic payload type > number to a particular codec within that media stream MUST NOT change > for the duration of a session. For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers for that media stream within the session. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. >=20 >=20 > This is true for the answerer as well. Thus, in each direction, once > PT number is bound to a codec, that PT number can not be used for a > different codec. >=20 > -Jonathan R. >=20 > Raman, Sundereshwaran (Sundereshwaran) wrote: >=20 > > I have question related to dynamic payloads. If a session is estblished > > with a dynamic payload type number mapped to a particular codec, can the > > number change for the same codec in subsequent offers/answers in the > > same session? e.g. Lets say a session was established with a dynamic > > payload type number 96 mapped to telephone-event. Now if a new Re-Invite > > is sent out, can the response have a different payload type number for > > the telephone event? > > > > Thanks > > Sundi > > > > >=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 > _______________________________________________ > 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 Aug 13 17:21: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 RAA06301 for ; Wed, 13 Aug 2003 17:21: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 19n33G-00011U-N4 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 17:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DLL2Px003931 for mmusic-archive@odin.ietf.org; Wed, 13 Aug 2003 17: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 19n33G-00011K-Jl for mmusic-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 17:21: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 RAA06285 for ; Wed, 13 Aug 2003 17:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n33E-0005A9-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 17:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19n33D-0005A6-00 for mmusic-web-archive@ietf.org; Wed, 13 Aug 2003 17:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n33E-00010t-ON; Wed, 13 Aug 2003 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19n339-00010f-9a for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 17:20: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 RAA06280 for ; Wed, 13 Aug 2003 17:20:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n337-0005A2-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:20:53 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19n336-00059s-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:20:52 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7DLKI3m003883; Wed, 13 Aug 2003 17:20:18 -0400 (EDT) Message-ID: <3F3AAB8E.3040502@dynamicsoft.com> Date: Wed, 13 Aug 2003 17:20:14 -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: "Raman, Sundereshwaran (Sundereshwaran)" CC: "Hearty, John" , mmusic@ietf.org Subject: Re: [MMUSIC] (no subject) 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 Raman, Sundereshwaran (Sundereshwaran) wrote: > Thanks for your prompt replies. I thought so too after reading the > RFC 3264. The reason for this question was I came across two > vendors who were changing the payload type number when a re-invite > was sent out. Heres the scenario: Session established with 96 as > the payload type number for telephone-event. I send out a RE-INVITE > with no SDP in it. The response from the phone contains a different > payload type number for the telephone event. Are they not supposed > to send the previous agreed upon payload type number? This is allowed. Read carefully below - it says that it IS ok for multiple numbers to be associated with the same codec. In other words, you can use PT 96 for tones, and then later PT 98 for tones. The opposite is NOT allowed. That is, payload type 96 cannot be used first for tones, and then for g.711. -Jonathan R. > -----Original Message----- From: Hearty, John > [mailto:John.Hearty@Level3.com] Sent: Wednesday, August 13, 2003 > 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran > (Sundereshwaran) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] (no > subject) > > > The text calls out the special case of disallowing changing the PT > in the case of RTP. The example was for telephone events. I > suspect you would risk interop problems if you didn't follow the > RTP rule in the text for telephone events, but technically the > example is removing the 96 PT and adding a different PT mapping to > telephone events which the text seems to allow. The rules are for > a particular media stream in the session. It may be safer to use a > whole new media stream for the new PT if you really need to do it > for some reason. > > John Hearty Level3 > > >> -----Original Message----- From: mmusic-admin@ietf.org >> [mailto:mmusic-admin@ietf.org] On Behalf > > Of > >> Jonathan Rosenberg Sent: Wednesday, August 13, 2003 2:39 PM To: >> Raman, Sundereshwaran (Sundereshwaran) Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] (no subject) >> >> I believe Section 8.3.2 of RFC 3264 directly answers your >> question: >> >> The list of media formats used in the session MAY be changed. To >> do this, the offerer creates a new media description, with the >> list > > of > >> media formats in the "m=" line different from the corresponding > > media > >> stream in the previous SDP. This list MAY include new formats, > > and > >> MAY remove formats present from the previous SDP. However, in >> the case of RTP, the mapping from a particular dynamic payload >> type number to a particular codec within that media stream MUST >> NOT > > change > >> for the duration of a session. For example, if A generates an > > offer > >> with G.711 assigned to dynamic payload type number 46, payload > > type > >> number 46 MUST refer to G.711 from that point forward in any > > offers > >> or answers for that media stream within the session. However, it >> > > is > >> acceptable for multiple payload type numbers to be mapped to the > > same > >> codec, so that an updated offer could also use payload type >> number > > 72 > >> for G.711. >> >> >> This is true for the answerer as well. Thus, in each direction, >> once PT number is bound to a codec, that PT number can not be >> used for a different codec. >> >> -Jonathan R. >> >> Raman, Sundereshwaran (Sundereshwaran) wrote: >> >> >>> I have question related to dynamic payloads. If a session is > > estblished > >>> with a dynamic payload type number mapped to a particular >>> codec, can > > the > >>> number change for the same codec in subsequent offers/answers >>> in the same session? e.g. Lets say a session was established >>> with a dynamic payload type number 96 mapped to >>> telephone-event. Now if a new > > Re-Invite > >>> is sent out, can the response have a different payload type >>> number > > for > >>> the telephone event? >>> >>> Thanks Sundi >>> >>> >> >> -- 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 > > -- 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 Aug 14 11:22: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 LAA14875 for ; Thu, 14 Aug 2003 11:22: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 19nJvS-000833-3R for mmusic-archive@odin.ietf.org; Thu, 14 Aug 2003 11:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EFM68X030937 for mmusic-archive@odin.ietf.org; Thu, 14 Aug 2003 11:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJvS-00082u-0I for mmusic-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 11:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14857 for ; Thu, 14 Aug 2003 11:22:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJvR-0003Pd-00 for mmusic-web-archive@ietf.org; Thu, 14 Aug 2003 11:22:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nJvQ-0003Pa-00 for mmusic-web-archive@ietf.org; Thu, 14 Aug 2003 11:22:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nJvN-00082V-7y; Thu, 14 Aug 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 19nJub-00081K-1R for mmusic@optimus.ietf.org; Thu, 14 Aug 2003 11:21: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 LAA14833 for ; Thu, 14 Aug 2003 11:21:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJua-0003P1-00 for mmusic@ietf.org; Thu, 14 Aug 2003 11:21:12 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19nJuZ-0003Ol-00 for mmusic@ietf.org; Thu, 14 Aug 2003 11:21:11 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h7EFKY3m004323; Thu, 14 Aug 2003 11:20:34 -0400 (EDT) Message-ID: <3F3BA8C0.5020605@dynamicsoft.com> Date: Thu, 14 Aug 2003 11:20:32 -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: "Raman, Sundereshwaran (Sundereshwaran)" CC: "Hearty, John" , mmusic@ietf.org Subject: Re: [MMUSIC] (no subject) 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 RFC 3264 is issued and done, and what you are proposing would change that behavior. I dont see the benefit of doing that. Changing PT numbers is sometimes necessary for synchronization of other changes. Normally I wouldn't expect it to change randomly. -Jonathan R. Raman, Sundereshwaran (Sundereshwaran) wrote: > Just a thought. I think its good to be flexible in having multiple > payload number for the same codec. But telephone-event is a special > codec type. It will be lot more easier if once a session is > established with a particular payload number for the > telephone-event, the same payload number is used for subsequent > offers/answers. This will particularly be beneficial to the PBX > world as many PBX features rely on the tones and if it keeps on > changing then lot more work needs to be done. I would appreciate > your views on this. > > Thanks Sundi > > -----Original Message----- From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 13, 2003 > 3:20 PM To: Raman, Sundereshwaran (Sundereshwaran) Cc: Hearty, > John; mmusic@ietf.org Subject: Re: [MMUSIC] (no subject) > > > > > Raman, Sundereshwaran (Sundereshwaran) wrote: > > >> Thanks for your prompt replies. I thought so too after reading >> the RFC 3264. The reason for this question was I came across two >> vendors who were changing the payload type number when a >> re-invite was sent out. Heres the scenario: Session established >> with 96 as the payload type number for telephone-event. I send >> out a RE-INVITE with no SDP in it. The response from the phone >> contains a different payload type number for the telephone event. >> Are they not supposed to send the previous agreed upon payload >> type number? > > > This is allowed. Read carefully below - it says that it IS ok for > multiple numbers to be associated with the same codec. In other > words, you can use PT 96 for tones, and then later PT 98 for tones. > The opposite is NOT allowed. That is, payload type 96 cannot be > used first for tones, and then for g.711. > > -Jonathan R. > > > >> -----Original Message----- From: Hearty, John >> [mailto:John.Hearty@Level3.com] Sent: Wednesday, August 13, 2003 >> 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran >> (Sundereshwaran) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] (no >> subject) >> >> >> The text calls out the special case of disallowing changing the >> PT in the case of RTP. The example was for telephone events. I >> suspect you would risk interop problems if you didn't follow the >> RTP rule in the text for telephone events, but technically the >> example is removing the 96 PT and adding a different PT mapping >> to telephone events which the text seems to allow. The rules are >> for a particular media stream in the session. It may be safer to >> use a whole new media stream for the new PT if you really need to >> do it for some reason. >> >> John Hearty Level3 >> >> >> >>> -----Original Message----- From: mmusic-admin@ietf.org >>> [mailto:mmusic-admin@ietf.org] On Behalf >> >> Of >> >> >>> Jonathan Rosenberg Sent: Wednesday, August 13, 2003 2:39 PM To: >>> Raman, Sundereshwaran (Sundereshwaran) Cc: mmusic@ietf.org >>> Subject: Re: [MMUSIC] (no subject) >>> >>> I believe Section 8.3.2 of RFC 3264 directly answers your >>> question: >>> >>> The list of media formats used in the session MAY be changed. >>> To do this, the offerer creates a new media description, with >>> the list >> >> of >> >> >>> media formats in the "m=" line different from the corresponding >>> >> >> media >> >> >>> stream in the previous SDP. This list MAY include new formats, >>> >> >> and >> >> >>> MAY remove formats present from the previous SDP. However, in >>> the case of RTP, the mapping from a particular dynamic payload >>> type number to a particular codec within that media stream MUST >>> NOT >> >> change >> >> >>> for the duration of a session. For example, if A generates an >> >> offer >> >> >>> with G.711 assigned to dynamic payload type number 46, payload >> >> type >> >> >>> number 46 MUST refer to G.711 from that point forward in any >> >> offers >> >> >>> or answers for that media stream within the session. However, >>> it >>> >> >> is >> >> >>> acceptable for multiple payload type numbers to be mapped to >>> the >> >> same >> >> >>> codec, so that an updated offer could also use payload type >>> number >> >> 72 >> >> >>> for G.711. >>> >>> >>> This is true for the answerer as well. Thus, in each direction, >>> once PT number is bound to a codec, that PT number can not be >>> used for a different codec. >>> >>> -Jonathan R. >>> >>> Raman, Sundereshwaran (Sundereshwaran) wrote: >>> >>> >>> >>>> I have question related to dynamic payloads. If a session is >> >> estblished >> >> >>>> with a dynamic payload type number mapped to a particular >>>> codec, can >> >> the >> >> >>>> number change for the same codec in subsequent offers/answers >>>> in the same session? e.g. Lets say a session was established >>>> with a dynamic payload type number 96 mapped to >>>> telephone-event. Now if a new >> >> Re-Invite >> >> >>>> is sent out, can the response have a different payload type >>>> number >> >> for >> >> >>>> the telephone event? >>>> >>>> Thanks Sundi >>>> >>>> >>> >>> -- 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 >> >> > -- 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 Aug 14 12:11: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 MAA16631 for ; Thu, 14 Aug 2003 12:11:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKgq-00030S-0P for mmusic-archive@odin.ietf.org; Thu, 14 Aug 2003 12:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7EGB3bX011550 for mmusic-archive@odin.ietf.org; Thu, 14 Aug 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKgp-00030D-T1 for mmusic-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 12:11: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 MAA16607 for ; Thu, 14 Aug 2003 12:10:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKgo-0003po-00 for mmusic-web-archive@ietf.org; Thu, 14 Aug 2003 12:11:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nKgn-0003pl-00 for mmusic-web-archive@ietf.org; Thu, 14 Aug 2003 12:11:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nKgn-0002zo-TD; Thu, 14 Aug 2003 12: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 19nKfp-0002xX-2t for mmusic@optimus.ietf.org; Thu, 14 Aug 2003 12:10: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 MAA16568 for ; Thu, 14 Aug 2003 12:09:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nKfn-0003p7-00 for mmusic@ietf.org; Thu, 14 Aug 2003 12:09:59 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19nKfm-0003p4-00 for mmusic@ietf.org; Thu, 14 Aug 2003 12:09:58 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7EG9t7W017018; Thu, 14 Aug 2003 18:09:55 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 14 Aug 2003 18:10:04 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4D8A@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (KI/EAB)" To: "'Colin Perkins'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-08.txt Date: Thu, 14 Aug 2003 18:08:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 Colin, and thanks for the comments. > > I have a number of comments on this draft: > > - The ABNF in Sections 2.1 and 2.2 is contradictory. The key management > data is defined as "text" in one section, and "quoted-string" in the > other, yet these two types have different ranges of valid characters > (and both are more liberal than the explanatory text, which implies > that only base-64 encoded data is allowed). Similar for the protocol > identifier: the definitions of "non-ws-string" in SDPnew and "token" > in RTSP are not consistent. This is as a result from the comments we received before, when we actually had consistent strings. At that time the comment was that we should use what was used in SDP and RTSP respectively (and the recommendations was to use non-ws-string and token). Please propose what to use. > - It should be stated that the protocol identifiers in Section 2.1 and > Section 2.2 refer to the same set of values, and a reference to the > registry of legal values should be given (i.e. reference the IANA > parameter registry defined in Section 6). Ok. > > - The draft repeatedly mentions Kerberos, and indicates that Kerberos > tickets may be included in key management messages, but does not > specify how this is to be achieved. Should either specify how to use > Kerberos, or remove all references to it. It was included as a result of a comment that we should give examples of more than one protocol that might utilize the framework. It is not our intention to specify how it can be used. We can agree that there are places where we could remove the reference. However, it might be good at least to keep the most general one in Section 3 to provide an overview of the possibilities. > - The second bullet point on Page 6 mentions that other parameters may > need to be specified for certain key management protocols, but does > not specify how an implementor knows if a particular key management > protocol uses additional parameters. Suggest this is listed as part > of the IANA registration for a particular key management protocol? I don't see why IANA should handle this. However, it sounds reasonable that it should be documented in the key management draft (or a companion draft). > - Section 3.1 seems to assume Offer/Answer usage. It is not clear how > it applies to SDP used with, for example, SAP, HTTP, or email? What > about one-to-many distribution of SDP? Or distributions where there > is no back-channel? It is acceptable for the draft to be explicit > about the limits of its scope, but it cannot ignore the wider problem > space. Ok, clarifications will be added. > - The discussion of authentication on Page 7 is not mentioned in the > list of things senders and receivers of SDP must do, on pages 5 and > 6. Ok, we can mention it there as well. > - Section 3.3 does not mention authentication. Should I assume that > there is no need for authentication when key management is used with > RTSP? Also in the RTSP case, the protocol name authentication described in section 3.1 should be applied. We will clarify this by explicitly state it. > - Section 4 needs to provide strict guidance about the parameters and > specifications needed for new key management protocols. The interface > between the key management protocol and this framework should be made > explicit. That is what we have tried to address. Please give examples of what you think is lacking of that? > - I find the arguments about security of the SDP in Section 5 weak. The > draft needs to be explicit about the threats it prevents and those it > leaves open. Recommend re-reading RFC 3553, Section 5. Ok. > - In section 5, how is a beat-down attack prevented when the attacker > wishes to beat-down to no security? What is the correct response to > an answer which suggests no security? That would be to terminate/abort the session setup. > - Section 6 needs to register the RTSP extensions needed, and make it > clear that the namespace for key management protocol identifiers is > shared between the RTSP and SDP extensions. Ok. > - Section 6 mentions that new key management protocols specify "the > syntax of possible additional arguments", yet this contradicts the > ABNF which states that only a single argument is present. Ok, that was a bad formulation. We'll fix that. > > The main issue behind these seems to be the desire to define new > parameters which can be left open for future uses. As was mentioned in > the context of the "a=gpmd:" attribute, this is not acceptable: there > needs to be a precise definition of the semantics of any new SDP > attribute/RTSP header before the draft can advance. Ok, but doesn't fixing the above issues make this problem go away? Fredrik > > -- > Colin Perkins > http://csperkins.org/ > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Aug 15 04:00:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21054 for ; Fri, 15 Aug 2003 04:00:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nZV6-00070w-CB for mmusic-archive@odin.ietf.org; Fri, 15 Aug 2003 03:59:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7F7xuWq026961 for mmusic-archive@odin.ietf.org; Fri, 15 Aug 2003 03:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nZV4-00070m-Ou for mmusic-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 03:59: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 DAA21029 for ; Fri, 15 Aug 2003 03:59:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nZV2-0000x2-00 for mmusic-web-archive@ietf.org; Fri, 15 Aug 2003 03:59:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nZV1-0000wy-00 for mmusic-web-archive@ietf.org; Fri, 15 Aug 2003 03:59:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nZUD-0006wT-DN; Fri, 15 Aug 2003 03:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nZTj-0006vu-Mz for mmusic@optimus.ietf.org; Fri, 15 Aug 2003 03:58: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 DAA21000; Fri, 15 Aug 2003 03:58:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nZTg-0000wR-00; Fri, 15 Aug 2003 03:58:28 -0400 Received: from imh.informatik.uni-bremen.de ([134.102.224.4]) by ietf-mx with esmtp (Exim 4.12) id 19nZTf-0000wE-00; Fri, 15 Aug 2003 03:58:28 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by imh.informatik.uni-bremen.de (8.12.9/8.12.9) with ESMTP id h7F7w3Xo016156; Fri, 15 Aug 2003 09:58:03 +0200 (MEST) Message-ID: <3F3C92E9.1050109@tzi.uni-bremen.de> Date: Fri, 15 Aug 2003 09:59:37 +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: minutes@ietf.org CC: 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] Final MMUSIC Minutes from 57th IETF Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 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, since we have not received any comments, we consider the minutes final. The slides are available at http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-ppt.zip http://www.dmn.tzi.org/ietf/mmusic/57/slides/57-mmusic-slides-pdf.zip Joerg ------------------------------------------------------------------------ Minutes of the MMUSIC WG Meeting at the 57th IETF ================================================= Reported by Joerg Ott and Colin Perkins Notes taken by Colin Perkins The MMUSIC WG met once at the 57th IETF. The meeting was chaired by Colin Perkins and Joerg Ott. It was attended by some 90 participants. Status Update ------------- Joerg Ott reported on the status of the working and the general progress since the 56th IETF in San Francisco: - The new charter was finally approved. - RFC 3524 was published on SDP extensions for reservation flows. - Two documents are with the RFC editor: SDP extensions for NAT traversal and SDPng transition. - Two documents are with the IESG, and comments have been received: - draft-rajeshkumar-mmusic-gpmd-03.txt was felt to overlap with work on capability negotiation carried out elsewhere; it was noted that this probably applies to most of SDP except that SDP was first. The chairs and authors will work with the IESG to sort this out. - draft-ietf-mmusic-sdp-new-13.txt received many comments which were discussed in a separate slot (see below). - Two documents are under AD review: - draft-ietf-mmusic-sdp-srcfilter-05.txt - draft-ietf-mmusic-sdp-comedia-05.txt - draft-ietf-mmusic-sdp-bwparam-04.txt is completing WGLC on 28 Jul 2003. - The SDP extensions for key management (draft-ietf-mmusic-kmgmt-ext-07.txt) have been waiting for the MIKEY work to complete which seems to progress. A further revision is expected shortly after the IETF. - The SDP implementation draft draft-ietf-mmusic-sdp-implem-00.txt has not been revised yet, but Tom Taylor is working on it. He is trying to incorporate further implementation experience from inside his company as well as from the SIPit events. Two potential new work items have been discussed for MMUSIC: - Real-time fax (draft-ietf-sipping-realtimefax-01.txt) from the SIPPING WG is to provide implementers with guidelines on how to use registered SDP attributes for ITU-T T.38. This document actually contains two logical parts: the use of offer/answer mechanics (which belongs to MMUSIC) and a discussion of SIP-specific signaling (which belongs to SIPPING). It is suggested to investigate splitting the document to deal with each one in the respective WG. But it was pointed out that this document merely contains examples only and hence should be done as a whole in just one WG. To be resolved. - Interactive connectivity establishment (ICE) also from the SIPPING WG (draft-rosenberg-sipping-ice-01.txt). This is discussed later on the agenda. Revised SDP (draft-ietf-mmusic-sdp-new-13.txt) ---------------------------------------------- Colin Perkins reported on the changes incorporated in the latest revision of SDP: It was attempted to clarify when the k= attribute may be used. Further clarifications include: RTP may be used with non-consecutive port numbers and a=charset is only allowed as a session level attribute. Also, unregistered X- attributes and media format are deprecated. Finally, IANA considerations and references were updated. Colin further reported on issues raised on revision -13 on the mailing list, as well as from the IESG review. - An ABNF inconsistency was found: a comment in the ABNF for "token-char" allowed for a larger set of characters than the actual definition. One could either (1) change the comment to match the actual grammar (and thus reduce the set of allowed characters) or (2) modify the grammar to match the comment. The group agreed to go with option (1), pending a check against the use of SDP in RFC 3108. Tom Taylor volunteered to find this out. - The use of b= with layered coding should be clarified as follows: When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. This was accepted in principle but it was also pointed out that a bandwidth specification per layer would be helpful. Further discussion is needed on the mailing list. - Again with layered coding, it should be clarified which ports are associated with an m= line. The clarification proposal was accepted. - The k= is underspecified. The most straightforward way would be to deprecate the use of this field altogether. Opinions from implementers are sought. It was reported that MS Messenger uses this field; the details are unknown at this moment though. As there are implementation out there, just deprecating this field won't work. Therefore, further work needs to go into the specification of using k=. In particular, when k= shall be used, a secure channel must be available and endpoints need to be sure that no third party can eavesdrop on the key. These issues, however, need to be specified by those using SDP rather than SDP itself. The k= field currently supports an algorithm indicator, but it should also specify a key type. This may be implied by the URI or the media protocol used. For more complex scenarios, e.g. when more than one key is needed, either the sdescriptions work (draft-ietf-mmusic-sdescriptions-01.txt) or the key management (draft-ietf-mmusic-kmgmt-ext-07.txt) work should be used. It was proposed that the security considerations section should change "SHOULD NOT deliver the user into an interactive multimedia session..." to "MUST NOT...". It was found that this is an issue of user authorization (e.g. the user may be able to pre-authorize the automatic joining of certain interactive sessions) and needs to be dealt with by the protocols using SDP. - The suggestion to define a "IN" value for private address spaces was rejected because systems 1) cannot tell whether they are in a private address space (relative to their peers) and 2) this change would be not backward compatible. - It will be clarified that UTF-8 normalization is not needed because comparisons are not done on fields with UTF-8. - Proposal on a=inactive: it was agreed not to change the SDP spec here (this is an issue for users of SDP, which may establish conventions for use, not for SDP itself). - Wording should be added that u= and k= may include URIs that may be dereferenced in some (but not all) cases. Also, it should be noted a k= URI may typically be an http or https URI. Both suggested wording additions were accepted. Colin will fold the comments and the discussion into the document and produce a new revision out within a couple of weeks. SDP Security Descriptions (draft-ietf-mmusic-sdescriptions-01.txt) ------------------------------------------------------------------ Dan Wing briefly reviewed the document and the changes from the previous revision: a new syntax is proposed for the a=crypto attribute and the offer/answer part is revised which may need further review. For the next steps, Colin noted that an IANA considerations section is needed, including a discussion of the registration procedures. Furthermore, reviewers for finishing the document were sought: Tom Taylor, Magnus Westerlund, and Martin Euchner volunteered. Offer/Answer Examples (draft-johnston-mmusic-offer-answer-examples-01.txt) -------------------------------------------------------------------------- Alan Johnston presented the changes to the document: in particular, an example for asymmetric use of a codec has been added. This is to be achieved using two distinct m= lines with the same port number, one indicating "sendonly", the other "recvonly". The proposed behavior caused some discussion: it was felt that the mechanism was underspecified and that (therefore) m= lines with the same port would be a bad idea. Yet, the right approach to achieve the desired behavior seemed unclear. Gonzalo Camarillo pointed out that the RFC3388 provided a similar example, but with an explicit grouping (which is not present in this draft). The applicability of RFC3388 to this problem was discussed further. Orit Levin pointed out that the intention clearly is to use RFC 3388 but the question is what happens to the endpoints that don't support RFC 3388. Gonzalo argued that this is already defined in RFC 3388. The chairs stated that they would like to see the asymmetric codec behavior with two m= line properly specified in a document. The present offer/answer examples draft is meant to be illustrative; the example should be kept in place (with added grouping) but the normative text for this behavior needs to be someplace else. Flemming Andreasen suggested to specify part of this practice in the revised SDP. SDPng Update (draft-ietf-mmusic-sdpng-06.txt) --------------------------------------------- Dirk Kutscher presented the latest progress on SDPng, addressing the open issues from draft -06 (a new revision still needs to be submitted). The SDPng structure has been enhanced to decouple capability negotiation for potential configurations from actual configuration (and the respective session parameters). While the capability model has been kept, the syntax has been revised to exclusively rely on XML mechanisms (rather than embedding own syntax conventions for attributes) -- which is less efficient but much cleaner. Dirk presented the new syntax using several examples and also showed a formal schema definition. A further refinement from draft -06 is to remove the concept of libraries and use inline definitions instead -- so that SDPng documents would be self-contained. There was little discussion. Steve Casner asked whether this work was getting enough traction and questioned whether people were really preparing for a transition. Joerg Ott argued that people are desparately holding onto SDP (which is perceived easier with one small extension at a time) -- but that examples show that this getting more complicated so that SDP is likely to have only a finite lifetime. So it would be nice to get broader review from the community on a replacements for SDP. RTP DoS Attacks (draft-rosenberg-mmusic-rtp-denialofservice-00.txt) Interactive Connectivity Establishment (draft-rosenberg-sipping-ice-01.txt) --------------------------------------------------------------------------- Jonathan Rosenberg introduced the RTP DoS problem: An attacker may easily direct the RTP stream(s) from an unsuspecting source to any target by providing the target's IP address in the SDP. This works for SIP and RTSP -- with RTSP providing limited protection by allowing unicast RTP streams only to the address of the originator (but NATs make it worse as anyone behind the same NAT can easily be attacked). As authentication mechanisms can at most help identify the attacker (which may be very weak though), some kind of handshake mechanism is needed so that sources do not start sending media streams unless they know that the right receiver is actually waiting for it: a request/response mechanism using the RTP ports is needed. This is ICE (see below) which has been chosen as a solution for SIP. However, ICE has broader applicability and may be appropriate for RTSP, too -- which needs to be determined by the group. Jonathan reviewed the properties of the ICE approach and briefly walked through the basic ICE algorithm. With ICE being signaling protocol independent, MMUSIC is asked to take ICE up as a WG item. ICE is felt to introduce quite some complexity for RTSP endpoints. If, however, NAT traversal (which is an RTSP issue on its own, see below) and security can be addressed by the same mechanism, it may be worth the effort. It is noted that even if we go for the ICE mechanism for RTSP right now, this does not solve the problem as long as old RTSP servers are still out there. Regarding the ICE proposal as a WG item Magnus Westerlund argued that if it is accepted, one should split the draft into several parts: the SIP use, the ICE mechanism, the use with offer/answer, etc. There was consensus in the group to accept ICE as new WG item, and to fully document the RTP DoS issues as an informational document. RTSP Update (draft-ietf-mmusic-rc2326bis-04.txt ----------------------------------------------- Magnus Westerlund reported on the progress of the RTSP revision, achieved by having a new co-editor joining the team, many teleconference calls, and also quite some list discussion. He presented a number of changes from draft -03 (see the slides). With this, most known open issues are resolved, with only a few ones remaining (see slides). But many resolutions still need to be folded into an updated revision of the draft. When this is done, a second phase of editing on the spec is needed: examples need to be fixed, the spec's consistency needs to be checked as needs it overall readability, and, potential new open issues need to be solved. With all this, the revised RTSP spec will not meet the October deadline as currently documented in the MMUSIC charter. Magnus suggests another six months would be appropriate to finalize the work. RTSP and NAT (draft-ietf-mmusic-rtsp-nat-01.txt) ------------------------------------------------ Magnus Westerlund introduced the revised draft on RTSP and NATs, the purpose of which is to describe how to traverse NATs and firewalls with RTSP. It documents several possible NAT traversal approaches and gives recommendations regarding RTSP for firewalls. Approaches requiring only modifications on the client side STUN, TURN, and RTP/RTSP tunneled in RTSP. Application-Layer Gateways (ALGs) for RTSP will not require any modifications -- but are generally discouraged. Magnus further discussed open issues, particurlarly the goals for RTSP for NATs (i.e. what type of scenarios should be achievable) as well as possible solutions (symmetric RTP, STUN, ICE, DCCP). On the ALGs: The group generally agreed that ALGs are a bad thing and should not be considered further (except for documentation purposes and to communicate this clearly to outside the IETF -- and fast, as people start deploying these). On the document's purpose: Commenters state that, currently, the draft does not give conclusive resolution of what to do as an implementer, it is merely an inventory. It is proposed to pick some solution and write it up, e.g. in the RTSP spec. Magnus wants to resolve the structure of the document and then settle on a solution: one for the server and one or more for the client side. Jonathan Rosenberg and Tom Marshal argue over the number of client-side solutions to be documented: Jonathan wants only one while Tom prefers to have multiple feasible solutions document. In case multiple ones are documented, Jonathan wants exactly one "MUST implement" solution to ensure interoperability. There was some further discussion on technical aspects of possible solutions, but no real conclusions were reached. Internet Media Guides (IMG) --------------------------- draft-nomura-mmusic-img-requirements-01.txt draft-nomura-mmusic-img-framework-01.txt After a brief introduction by Joerg Ott, Rod Walsh presented the progress on the IMG requirements document (which will be re-submitted as WG draft by end of August). He briefly reviewed the general topology and IMG distribution aspects and then went through the requirement categories identified in the draft: IMG description requirements and IMG transport requirements. The former primarily address IMG envelopes for existing meta-data formats, the latter their distribution in unicast and multicast, pull and push style scenarios. For multicast push, SAPv2 is probably inadequate, so a successor is sought, e.g. ALC from the RMT WG. It is pointed that additions to ALC need to be specified separately; while Rod wants to use the RMT proposal FLUTE, Lorenzo argues that this may not be 100% appropriate here; Lorenzo also points out that possible tasks in the RMT WG need to happen quickly as the group is trying to wrap up. For unicasting, client-initiated actions could use HTTP while notifications from the server could use SIP mechanims. Rod discusses on the scalability requirements IMG transport and presents a conceptual overview showing the different pieces of an IMG framework and outlines the achieved flexibility. He also addresses data relationships and particularly security considerations as taken into account in the requirements draft. Rod finally discusses the way ahead: the requirements draft is pretty close to finalization; the remaining efforts are mainly editorial and consolidation. The aim is to go for WGLC soon. He also points to the existing framework draft that will be revised by the end of August. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Aug 17 13:17: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 NAA16425 for ; Sun, 17 Aug 2003 13:17: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 19oR9P-000797-AU for mmusic-archive@odin.ietf.org; Sun, 17 Aug 2003 13:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HHH7rv027453 for mmusic-archive@odin.ietf.org; Sun, 17 Aug 2003 13: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 19oR9P-00078g-6b for mmusic-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 13: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 NAA16418 for ; Sun, 17 Aug 2003 13:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oR9M-0001mA-00 for mmusic-web-archive@ietf.org; Sun, 17 Aug 2003 13:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oR9L-0001m2-00 for mmusic-web-archive@ietf.org; Sun, 17 Aug 2003 13: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 19oR9J-00077m-3X; Sun, 17 Aug 2003 13: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 19n2uO-0000gM-JM for mmusic@optimus.ietf.org; Wed, 13 Aug 2003 17:11: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 RAA06094 for ; Wed, 13 Aug 2003 17:11:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19n2uM-00057D-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:11:50 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 19n2uL-00057A-00 for mmusic@ietf.org; Wed, 13 Aug 2003 17:11:49 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7DLAiCi009168 for ; Wed, 13 Aug 2003 16:10:44 -0500 (EST) Received: from cof110avexu2.global.avaya.com (h135-9-6-17.avaya.com [135.9.6.17]) by tierw.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7DLAhCi009157 for ; Wed, 13 Aug 2003 16:10:43 -0500 (EST) 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] (no subject) Date: Wed, 13 Aug 2003 15:11:47 -0600 Message-ID: Thread-Topic: [MMUSIC] (no subject) Thread-Index: AcNh21wTGt9wWOt7TbSQJ3jNw9nVcgAAEe+QAACSQSA= From: "Raman, Sundereshwaran (Sundereshwaran)" To: "Hearty, John" , "Jonathan Rosenberg" Cc: Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for your prompt replies. I thought so too after reading the RFC = 3264. The reason for this question was I came across two vendors who were = changing the payload type number when a re-invite was sent out. Heres = the scenario: Session established with 96 as the payload type number for = telephone-event. I send out a RE-INVITE with no SDP in it. The response from the phone = contains a different payload type number for the telephone event. Are = they not supposed to send the previous agreed upon payload type number? = Thanks Sundi -----Original Message----- From: Hearty, John [mailto:John.Hearty@Level3.com] Sent: Wednesday, August 13, 2003 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran (Sundereshwaran) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] (no subject) The text calls out the special case of disallowing changing the PT in the case of RTP. The example was for telephone events. I suspect you would risk interop problems if you didn't follow the RTP rule in the text for telephone events, but technically the example is removing the 96 PT and adding a different PT mapping to telephone events which the text seems to allow. The rules are for a particular media stream in the session. It may be safer to use a whole new media stream for the new PT if you really need to do it for some reason. John Hearty Level3 > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of > Jonathan Rosenberg > Sent: Wednesday, August 13, 2003 2:39 PM > To: Raman, Sundereshwaran (Sundereshwaran) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] (no subject) >=20 > I believe Section 8.3.2 of RFC 3264 directly answers your question: >=20 > The list of media formats used in the session MAY be changed. To do > this, the offerer creates a new media description, with the list of > media formats in the "m=3D" line different from the corresponding media > stream in the previous SDP. This list MAY include new formats, and > MAY remove formats present from the previous SDP. However, in the > case of RTP, the mapping from a particular dynamic payload type > number to a particular codec within that media stream MUST NOT change > for the duration of a session. For example, if A generates an offer > with G.711 assigned to dynamic payload type number 46, payload type > number 46 MUST refer to G.711 from that point forward in any offers > or answers for that media stream within the session. However, it is > acceptable for multiple payload type numbers to be mapped to the same > codec, so that an updated offer could also use payload type number 72 > for G.711. >=20 >=20 > This is true for the answerer as well. Thus, in each direction, once > PT number is bound to a codec, that PT number can not be used for a > different codec. >=20 > -Jonathan R. >=20 > Raman, Sundereshwaran (Sundereshwaran) wrote: >=20 > > I have question related to dynamic payloads. If a session is estblished > > with a dynamic payload type number mapped to a particular codec, can the > > number change for the same codec in subsequent offers/answers in the > > same session? e.g. Lets say a session was established with a dynamic > > payload type number 96 mapped to telephone-event. Now if a new Re-Invite > > is sent out, can the response have a different payload type number for > > the telephone event? > > > > Thanks > > Sundi > > > > >=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 > _______________________________________________ > 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 Aug 17 14:03: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 NAA16426 for ; Sun, 17 Aug 2003 13:17: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 19oR9P-000796-AS for mmusic-archive@odin.ietf.org; Sun, 17 Aug 2003 13:17:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7HHH7ab027458 for mmusic-archive@odin.ietf.org; Sun, 17 Aug 2003 13: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 19oR9P-00078h-70 for mmusic-web-archive@optimus.ietf.org; Sun, 17 Aug 2003 13: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 NAA16417 for ; Sun, 17 Aug 2003 13:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oR9M-0001m7-00 for mmusic-web-archive@ietf.org; Sun, 17 Aug 2003 13:17:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oR9L-0001m1-00 for mmusic-web-archive@ietf.org; Sun, 17 Aug 2003 13: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 19oR9J-00077u-DU; Sun, 17 Aug 2003 13: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 19nJHL-0005yY-2p for mmusic@optimus.ietf.org; Thu, 14 Aug 2003 10:40:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12550 for ; Thu, 14 Aug 2003 10:40:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nJHI-0002jz-00 for mmusic@ietf.org; Thu, 14 Aug 2003 10:40:36 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 19nJHH-0002jw-00 for mmusic@ietf.org; Thu, 14 Aug 2003 10:40:35 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7EEdTCi023751 for ; Thu, 14 Aug 2003 09:39:29 -0500 (EST) Received: from cof110avexu2.global.avaya.com (h135-9-6-17.avaya.com [135.9.6.17]) by tierw.net.avaya.com (Switch-3.1.0/Switch-3.1.0) with ESMTP id h7EEdSCi023727 for ; Thu, 14 Aug 2003 09:39:28 -0500 (EST) 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] (no subject) Date: Thu, 14 Aug 2003 08:40:33 -0600 Message-ID: Thread-Topic: [MMUSIC] (no subject) Thread-Index: AcNh4LUZ+pQuXtnHQtKpZB2mpWp2mwAkEMNw From: "Raman, Sundereshwaran (Sundereshwaran)" To: "Jonathan Rosenberg" Cc: "Hearty, John" , 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 Just a thought. I think its good to be flexible in having multiple = payload number for the same codec. But telephone-event is a special = codec type. It will be lot more easier if once a session is established = with a particular payload number for the telephone-event, the same = payload number is used for subsequent offers/answers. This will = particularly be beneficial to the PBX world as many PBX features rely on = the tones and if it keeps on changing then lot more work needs to be = done. I would appreciate your views on this. Thanks Sundi -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, August 13, 2003 3:20 PM To: Raman, Sundereshwaran (Sundereshwaran) Cc: Hearty, John; mmusic@ietf.org Subject: Re: [MMUSIC] (no subject) Raman, Sundereshwaran (Sundereshwaran) wrote: > Thanks for your prompt replies. I thought so too after reading the > RFC 3264. The reason for this question was I came across two > vendors who were changing the payload type number when a re-invite > was sent out. Heres the scenario: Session established with 96 as > the payload type number for telephone-event. I send out a RE-INVITE > with no SDP in it. The response from the phone contains a different > payload type number for the telephone event. Are they not supposed > to send the previous agreed upon payload type number? This is allowed. Read carefully below - it says that it IS ok for=20 multiple numbers to be associated with the same codec. In other words,=20 you can use PT 96 for tones, and then later PT 98 for tones. The=20 opposite is NOT allowed. That is, payload type 96 cannot be used first=20 for tones, and then for g.711. -Jonathan R. > -----Original Message----- From: Hearty, John > [mailto:John.Hearty@Level3.com] Sent: Wednesday, August 13, 2003 > 2:49 PM To: Jonathan Rosenberg; Raman, Sundereshwaran > (Sundereshwaran) Cc: mmusic@ietf.org Subject: RE: [MMUSIC] (no > subject) >=20 >=20 > The text calls out the special case of disallowing changing the PT > in the case of RTP. The example was for telephone events. I > suspect you would risk interop problems if you didn't follow the > RTP rule in the text for telephone events, but technically the > example is removing the 96 PT and adding a different PT mapping to > telephone events which the text seems to allow. The rules are for > a particular media stream in the session. It may be safer to use a > whole new media stream for the new PT if you really need to do it > for some reason. >=20 > John Hearty Level3 >=20 >=20 >> -----Original Message----- From: mmusic-admin@ietf.org >> [mailto:mmusic-admin@ietf.org] On Behalf >=20 > Of >=20 >> Jonathan Rosenberg Sent: Wednesday, August 13, 2003 2:39 PM To: >> Raman, Sundereshwaran (Sundereshwaran) Cc: mmusic@ietf.org=20 >> Subject: Re: [MMUSIC] (no subject) >>=20 >> I believe Section 8.3.2 of RFC 3264 directly answers your >> question: >>=20 >> The list of media formats used in the session MAY be changed. To >> do this, the offerer creates a new media description, with the >> list >=20 > of >=20 >> media formats in the "m=3D" line different from the corresponding >=20 > media >=20 >> stream in the previous SDP. This list MAY include new formats, >=20 > and >=20 >> MAY remove formats present from the previous SDP. However, in >> the case of RTP, the mapping from a particular dynamic payload >> type number to a particular codec within that media stream MUST >> NOT >=20 > change >=20 >> for the duration of a session. For example, if A generates an >=20 > offer >=20 >> with G.711 assigned to dynamic payload type number 46, payload >=20 > type >=20 >> number 46 MUST refer to G.711 from that point forward in any >=20 > offers >=20 >> or answers for that media stream within the session. However, it >>=20 >=20 > is >=20 >> acceptable for multiple payload type numbers to be mapped to the >=20 > same >=20 >> codec, so that an updated offer could also use payload type >> number >=20 > 72 >=20 >> for G.711. >>=20 >>=20 >> This is true for the answerer as well. Thus, in each direction, >> once PT number is bound to a codec, that PT number can not be >> used for a different codec. >>=20 >> -Jonathan R. >>=20 >> Raman, Sundereshwaran (Sundereshwaran) wrote: >>=20 >>=20 >>> I have question related to dynamic payloads. If a session is >=20 > estblished >=20 >>> with a dynamic payload type number mapped to a particular >>> codec, can >=20 > the >=20 >>> number change for the same codec in subsequent offers/answers >>> in the same session? e.g. Lets say a session was established >>> with a dynamic payload type number 96 mapped to >>> telephone-event. Now if a new >=20 > Re-Invite >=20 >>> is sent out, can the response have a different payload type >>> number >=20 > for >=20 >>> the telephone event? >>>=20 >>> Thanks Sundi >>>=20 >>>=20 >>=20 >> -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza=20 >> 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 >> _______________________________________________ mmusic mailing >> list mmusic@ietf.org=20 >> https://www1.ietf.org/mailman/listinfo/mmusic >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Aug 18 18:33: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 SAA07973 for ; Mon, 18 Aug 2003 18:33: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 19osYn-0008VN-Lz for mmusic-archive@odin.ietf.org; Mon, 18 Aug 2003 18:33:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IMX9nE032693 for mmusic-archive@odin.ietf.org; Mon, 18 Aug 2003 18:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osYn-0008VE-HK for mmusic-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 18:33: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 SAA07970 for ; Mon, 18 Aug 2003 18:33:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osYk-00037A-00 for mmusic-web-archive@ietf.org; Mon, 18 Aug 2003 18:33:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19osYj-000376-00 for mmusic-web-archive@ietf.org; Mon, 18 Aug 2003 18:33:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19osYe-0008Um-NT; Mon, 18 Aug 2003 18: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 19osXu-0008UY-SZ for mmusic@optimus.ietf.org; Mon, 18 Aug 2003 18:32:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07957 for ; Mon, 18 Aug 2003 18:32:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19osXr-000371-00 for mmusic@ietf.org; Mon, 18 Aug 2003 18:32:11 -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 19osXq-00036m-00 for mmusic@ietf.org; Mon, 18 Aug 2003 18:32:10 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2003 15:38:53 -0700 Received: from cscoamera13263.cisco.com (rtp-vpn2-492.cisco.com [10.82.241.236]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7IMVHxd020269; Mon, 18 Aug 2003 18:31:18 -0400 (EDT) Message-Id: <5.1.1.5.2.20030818144707.058a0520@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 18 Aug 2003 15:31:16 -0700 To: "Dan Wing" , Magnus Westerlund From: Mark Baugher Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt Cc: "Flemming Andreasen" , "IETF MMUSIC WG" In-Reply-To: References: <3F214784.2030804@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, Dan Thanks to Magnus for the careful review. Pardon my late response but we are now about ready to revise the I-D and can benefit from an exchange on these issues. I have a few comments below. At 04:21 PM 7/30/2003 -0700, Dan Wing wrote: > > 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. Yes and this is a shift from draft 0. Here is our thought process: We will not be implementing sdescriptions for anything but the RTP/SAVP (we never planned to specify security descriptions for media, which is something that I'd expect to see in the fmtp). I think we'd be making a mistake to specify something that we don't plan to implement and the result will likely have a lot of errors, which will likely only be discovered when someone tries to implement it. This is what I think happened with k=. If k= was implemented, it was too narrow and the result is that it needs to be replaced. That being said, I believe this framework is general enough to be used by other SDP transports. But we really are only providing the definitions for RTP/SAVP. > > 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? Yes, session parameters are distinct from key parameters. The crypto-suite are specific to the key parameters and independent from the session parameters. > > 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). I think we'll be more future-proof if we just face the fact that encryption and authentication transforms can often be specialized to the transport. That is what happened to counter mode in IPsec versus SRTP. TBS, I don't see any reason why a specification for a specific transport other than RTP/SAVP cannot reference an RTP/SAVP crypto-suite. This will give us the benefit of reuse without trying to force a single definition on all transports. > > 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. We are discussing this. I imagine that the URI will take a person to a web page for the purposes of authorization. After that, the key can be obtained by application-specific means, e.g. it could be sent in email. Or as Magnus has pointed out, the format can be crypto-suite dependent and the format of the key can be as described in the sdescriptions draft. Personally, I don't think we need to define this further but leave it to an application. It's more flexible that way. > > 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. I don't think any one of the three are always sufficient. The fact that we need to intrude into RTP processing in this way is a drawback to SRTP. The SSRC is needed to identify the crypto context prior to the start of the RTP session. In a pair-wise session, or if there is only a single sender, the SSRC might not be needed. In general, it will be. The ROC and SEQ are needed to generate the SRTP keystream for AES-CM and f8. If the receiver does not join the session after session commencement, the ROC and SEQ might not be needed. But because the SEQ starts at a random value in RTP, we need to account for boundary cases where the SEQ starts very close to its maximum value. All of this is very messy. But in a pairwise session of short duration, where the SEQ starts at zero, the SEQ and ROC do not need to be signaled. > > 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-? I'd prefer that we just point to the SRTP specification. > > 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. yes, thanks. Mark >-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 From exim@www1.ietf.org Tue Aug 19 07:40: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 HAA05539 for ; Tue, 19 Aug 2003 07:40: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 19p4qL-00010a-0M for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07:40:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JBe4p3003872 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p4qK-00010N-SL for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 07:40: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 HAA05524 for ; Tue, 19 Aug 2003 07:40:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p4qK-0006qf-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07:40:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p4qJ-0006qc-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07:40:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p4qH-0000zq-65; Tue, 19 Aug 2003 07:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p4q4-0000zN-Kn for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 07:39: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 HAA05520 for ; Tue, 19 Aug 2003 07:39:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p4q3-0006qY-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:39:47 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19p4q3-0006qU-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:39:47 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7JBdf7W014160; Tue, 19 Aug 2003 13:39:41 +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 QXY9WXK5; Tue, 19 Aug 2003 13:40:02 +0200 Message-ID: <3F420C73.8040309@ericsson.com> Date: Tue, 19 Aug 2003 13:39:31 +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: Dan Wing CC: Flemming Andreasen , Mark Baugher , IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt 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 Dan, My clarifications and further comments below: Dan Wing wrote: >>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. > Okay, the question is if this is acceptable. As I can see it there are two ways when defining "a=crypto" 1. As a future safe replacement of a=k with possibility to declare new ways of transporting the keys by using a place holder. That way one could in the future define a=crypto to be valid also for other profiles and media types. 2. Only define a=crypto for SRTP. However there are still need to for the possibility to extend it for future crypto suites for SRTP. Personally I don't have any strong view on the alternatives. However I feel there is need for some discussion on what the correct way forward is. There also seem to exist possibilities that some of the k= usage should actually be defined using a=crypto to take care of all concerns regarding what encryption method is used etc. > >>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? > I think you helped explain the problem here. First, the session parameters that can be used are always in relation to the crypto suit. This means that each crypto suit needs to define which parameters that are valid for the crypto suit. Secondly there are certain parameters that will be present in all SRTP suites so far defined. Taking the "encrypted_srtcp" as an example. Can't a future crypto suit define that RTCP will always be encrypted and the need for the parameter is removed. This may not be a good way of defining it, however it is possible. So the point I try to make is that each crypto suit should define what parameters it supports. > >>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). Depending on what is the agreed on path, this comment either goes away or needs to be addressed. >>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.) > I don't see a problem with defining it this way. However there is need to clearly define that this specification does not cover the case with multiple m= line for the same port. >> 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-? > Yes, and explanation on how the parameters a=crypto are used for this purpose. > >>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? As SRTP-WINDOW-SIZE is application dependent there might be need for an application to hint how big this window should be to work satisfactory. However there might be enough information given in SDP attributes like a=maxprate and the bandwidth modifiers to allow a receiving side to derive the parameters. One could allow the parameter as a hint to the application. 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 Tue Aug 19 07:51: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 HAA05854 for ; Tue, 19 Aug 2003 07:51: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 19p50w-0001HU-Du for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JBp2FT004886 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07: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 19p50w-0001GK-9O for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 07: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 HAA05846 for ; Tue, 19 Aug 2003 07:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p50v-0006uu-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p50u-0006ur-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07: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 19p50u-0001Fq-Ql; Tue, 19 Aug 2003 07: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 19p50p-0001FY-4R for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 07:50: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 HAA05843 for ; Tue, 19 Aug 2003 07:50:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p50o-0006un-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:50:54 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19p50n-0006uk-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:50:53 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7JBop7W018066; Tue, 19 Aug 2003 13:50:51 +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 QY1JD2GS; Tue, 19 Aug 2003 13:51:18 +0200 Message-ID: <3F420F11.9030506@ericsson.com> Date: Tue, 19 Aug 2003 13:50:41 +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: Rod.Walsh@nokia.com CC: csp@csperkins.org, mmusic@ietf.org, jo@tzi.uni-bremen.de Subject: Re: [MMUSIC] WG Last call: draft-ietf-mmusic-sdp-bwparam-04.txt References: <2BF0AD29BC31FE46B78877321144043101B9E466@trebe003.europe.nokia.com> In-Reply-To: <2BF0AD29BC31FE46B78877321144043101B9E466@trebe003.europe.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rod, Thanks for the review. I don't see a problem with the usage on session level you propose. The original intent of the change was to allow for stream combinations that has there bit-rate peaks at different places to be correctly expressed when given as combination. If an application uses the necessary SDP extension to understand that certain media tracks are alternatives to other I don't see any problem. The type will be fixed in AUTH48 unless other comments result in a new version (I hope not). Best Regards Magnus Rod.Walsh@nokia.com wrote: > 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 >> >> >>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 >> > > -- 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 Aug 19 07:58: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 HAA05966 for ; Tue, 19 Aug 2003 07:58: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 19p57j-0001R9-J0 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JBw39v005517 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 07:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p57j-0001Qu-Fq for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 07:58: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 HAA05950 for ; Tue, 19 Aug 2003 07:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p57i-0006wX-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07:58:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p57h-0006wU-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 07:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p57h-0001QT-89; Tue, 19 Aug 2003 07: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 19p57C-0001QF-8U for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 07:57: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 HAA05945 for ; Tue, 19 Aug 2003 07:57:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p57B-0006wL-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:57:29 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19p57A-0006wI-00 for mmusic@ietf.org; Tue, 19 Aug 2003 07:57:28 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7JBvN7W020290; Tue, 19 Aug 2003 13:57:23 +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 QXYYYC4B; Tue, 19 Aug 2003 13:57:23 +0200 Message-ID: <3F421099.8010508@ericsson.com> Date: Tue, 19 Aug 2003 13:57:13 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Enrico Balatti CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility References: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> In-Reply-To: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Enrico, I have not had time to read the paper by Schulzrinne. However from what=20 I understand this should be possible to do in RTSP. However it touches=20 upon grey zones in the specification in two ways. The connection between = RTSP message transport and session, that should not exist. And the usage = of SETUP to change transport parameters. Therefore I am not surprised=20 that the Darwin server does not work in your experiments. I think the Darwin server connects the TCP connection to the session and = that the session actually is deleted if the TCP connection is removed. There is no discussion of how to use RTSP for application layer=20 mobility. Are there a need for such a chapter in the specification or as = a separate draft? Best Regards Magnus Enrico Balatti wrote: > Dear Ashutosh, >=20 > thank you for you quickly reply. >=20 > 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. >=20 > 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. >=20 > I don't know if this mean that the Server is not RTSP standard complian= t. >=20 > Do you know where the RTSP specification=20 > talks about the RTSP application-mobility? >=20 > Thanks, > Enrico >=20 >=20 > -----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 >=20 >=20 >=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. >=20 > Thanks > Ashutosh >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=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 Tue Aug 19 08:58: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 IAA08257 for ; Tue, 19 Aug 2003 08:58: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 19p63n-0003dB-PJ for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 08:58:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JCw3fY013951 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 08:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p63n-0003cw-Jj for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 08:58: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 IAA08247 for ; Tue, 19 Aug 2003 08:57:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p63m-0007Xq-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 08:58:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p63l-0007Xn-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 08:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p63l-0003cW-4o; Tue, 19 Aug 2003 08: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 19p63A-0003c4-8m for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 08:57: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 IAA08223 for ; Tue, 19 Aug 2003 08:57:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p638-0007XI-00 for mmusic@ietf.org; Tue, 19 Aug 2003 08:57:22 -0400 Received: from breeze.research.telcordia.com ([192.4.6.9]) by ietf-mx with esmtp (Exim 4.12) id 19p638-0007X9-00 for mmusic@ietf.org; Tue, 19 Aug 2003 08:57:22 -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 h7JCuQn6009747; Tue, 19 Aug 2003 08:56:26 -0400 (EDT) Message-Id: <200308191256.h7JCuQn6009747@breeze.research.telcordia.com> To: Magnus Westerlund cc: Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility In-reply-to: Your message of "Tue, 19 Aug 2003 13:57:13 +0200." <3F421099.8010508@ericsson.com> Date: Tue, 19 Aug 2003 08:56:26 -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: , A combination of SETUP and PLAY as described in 10.4 and 10.5 of RFC 2326 should be able to handle the mobility of RTP stream. It should be similar to using SIP Re-INVITE to take care of mid-session mobility for RTP stream. It could be that SETUP message has to be over UDP to make it work instead of TCP in case of IP address change? Thanks Ashutosh > Hi Enrico, > > I have not had time to read the paper by Schulzrinne. However from what=20 > I understand this should be possible to do in RTSP. However it touches=20 > upon grey zones in the specification in two ways. The connection between = > > RTSP message transport and session, that should not exist. And the usage = > > of SETUP to change transport parameters. Therefore I am not surprised=20 > that the Darwin server does not work in your experiments. > > I think the Darwin server connects the TCP connection to the session and = > > that the session actually is deleted if the TCP connection is removed. > > There is no discussion of how to use RTSP for application layer=20 > mobility. Are there a need for such a chapter in the specification or as = > > a separate draft? > > Best Regards > > Magnus > > Enrico Balatti wrote: > > > Dear Ashutosh, > >=20 > > thank you for you quickly reply. > >=20 > > 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. > >=20 > > 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. > >=20 > > I don't know if this mean that the Server is not RTSP standard complian= > t. > >=20 > > Do you know where the RTSP specification=20 > > talks about the RTSP application-mobility? > >=20 > > Thanks, > > Enrico > >=20 > >=20 > > -----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 > >=20 > >=20 > >=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. > >=20 > > Thanks > > Ashutosh > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=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 Ashutosh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 19 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 LAA17462 for ; Tue, 19 Aug 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 19p8EM-0001FN-6I for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 11:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JFH61m004788 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 11:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p8EM-0001F9-2N for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 11:17: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 LAA17451 for ; Tue, 19 Aug 2003 11:17:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p8EL-0001wN-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 11:17:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p8EK-0001wK-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 11:17:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p8EH-0001EE-P3; Tue, 19 Aug 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 19p8Dp-0001D0-Rt for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 11:16: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 LAA17383 for ; Tue, 19 Aug 2003 11:16:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p8Do-0001uu-00 for mmusic@ietf.org; Tue, 19 Aug 2003 11:16:32 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 19p8Dn-0001ul-00 for mmusic@ietf.org; Tue, 19 Aug 2003 11:16:31 -0400 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h7JFGA8I009409; Tue, 19 Aug 2003 11:16:10 -0400 (EDT) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id h7JFG9J10812; Tue, 19 Aug 2003 11:16:09 -0400 Message-ID: <3F423F29.5030708@cs.columbia.edu> Date: Tue, 19 Aug 2003 11:15:53 -0400 From: Henning Schulzrinne Organization: Columbia University 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: Magnus Westerlund CC: Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility References: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> <3F421099.8010508@ericsson.com> In-Reply-To: <3F421099.8010508@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cs.columbia.edu id h7JFGA8I009409 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 Since this is a source of interoperability problems, some basic=20 discussions on transport behavior seems helpful for the base spec. You=20 can't fix the problems with an additional spec. I don't think this has=20 to be complicated, but address changes are now not uncommon for=20 long-lived sessions (e.g., due to multi-homed hosts, DHCP or moving=20 around between 802.11 APs.) Magnus Westerlund wrote: > Hi Enrico, >=20 > I have not had time to read the paper by Schulzrinne. However from what= =20 > I understand this should be possible to do in RTSP. However it touches=20 > upon grey zones in the specification in two ways. The connection betwee= n=20 > RTSP message transport and session, that should not exist. And the usag= e=20 > of SETUP to change transport parameters. Therefore I am not surprised=20 > that the Darwin server does not work in your experiments. >=20 > I think the Darwin server connects the TCP connection to the session an= d=20 > that the session actually is deleted if the TCP connection is removed. >=20 > There is no discussion of how to use RTSP for application layer=20 > mobility. Are there a need for such a chapter in the specification or a= s=20 > a separate draft? >=20 > Best Regards >=20 > Magnus >=20 > Enrico Balatti wrote: >=20 >> 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 the=20 >> 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 complia= nt. >> >> Do you know where the RTSP specification talks about the RTSP=20 >> 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 >> >> >> 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 >> >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Aug 19 12:10: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 MAA20587 for ; Tue, 19 Aug 2003 12:10: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 19p93c-0004Gu-Pz for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 12:10:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGA4Cr016417 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 12:10:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p93c-0004Gi-I7 for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:10: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 MAA20582 for ; Tue, 19 Aug 2003 12:09:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p93b-0002pc-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 12:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p93a-0002pZ-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 12:10:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p93Y-0004Ef-PL; Tue, 19 Aug 2003 12:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p92v-0004DL-Km for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 12:09: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 MAA20525 for ; Tue, 19 Aug 2003 12:09:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p92u-0002ot-00 for mmusic@ietf.org; Tue, 19 Aug 2003 12:09:20 -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 19p92t-0002oR-00 for mmusic@ietf.org; Tue, 19 Aug 2003 12:09:19 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2003 09:16:13 -0700 Received: from cscoamera13263.cisco.com (rtp-vpn1-243.cisco.com [10.82.224.243]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h7JG8KAd002213; Tue, 19 Aug 2003 12:08:21 -0400 (EDT) Message-Id: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 19 Aug 2003 09:08:19 -0700 To: Magnus Westerlund From: Mark Baugher Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt Cc: Dan Wing , Flemming Andreasen , IETF MMUSIC WG In-Reply-To: <3F420C73.8040309@ericsson.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, At 01:39 PM 8/19/2003 +0200, Magnus Westerlund wrote: >Hi Dan, > >My clarifications and further comments below: > >Dan Wing wrote: > >>>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. > >Okay, the question is if this is acceptable. As I can see it there are two >ways when defining "a=crypto" > >1. As a future safe replacement of a=k Do you mean k=? >with possibility to declare new ways of transporting the keys by using a >place holder. That way one could in the future define a=crypto to be valid >also for other profiles and media types. > >2. Only define a=crypto for SRTP. However there are still need to for the >possibility to extend it for future crypto suites for SRTP. > >Personally I don't have any strong view on the alternatives. However I >feel there is need for some discussion on what the correct way forward is. > >There also seem to exist possibilities that some of the k= usage should >actually be defined using a=crypto to take care of all concerns regarding >what encryption method is used etc. I think that a=crypto does everything that k= does. My concern is that there might be an unforeseen need for extension for a particular 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? > >I think you helped explain the problem here. First, the session parameters >that can be used are always in relation to the crypto suit. No, this is not the case: They are specific to the transport. The crypto-suite may or may not be specific to the transport (see below). >This means that each crypto suit needs to define which parameters that are >valid for the crypto suit. Secondly there are certain parameters that will >be present in all SRTP suites so far defined. > >Taking the "encrypted_srtcp" as an example. Can't a future crypto suit >define that RTCP will always be encrypted and the need for the parameter >is removed. This may not be a good way of defining it, however it is possible. I suppose it is but it would be a very brittle way to define the crypto suite, which *may be* orthogonal to the transport. In the first submission of this work, we expected the crypto suite to be transport independent. The reason it is not is because we have seen examples of the crypto suite being tailored and optimized for a particular transport. For example, AES counter mode for SRTP re-uses the RTP sequence number to obviate the need to add a nonce to the header and save precious bits on low bandwidth links. IPsec decided to put a nonce into the IPsec transport header for AES counter mode - the IV field - rather than overload the sequence number. For sdescriptions, it seemed to us to be safer to not try and develop a single set of crypto suites for all transports since the namespace could become unwieldy (e.g. AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC). You seem to be taking this to its logical conclusion of putting all transport-specific parameters into the crypto suite, but I don't think we want to do that. For one thing, it will result in too many crypto suites. A bigger problem is that some parameter support a range of values, such as the size of the MKI. >So the point I try to make is that each crypto suit should define what >parameters it supports. We made a distinction of parameters that are specific to the key, these are the domain of the crypto suite, versus parameters related to the transport, these are the session parameters. >>>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). > >Depending on what is the agreed on path, this comment either goes away or >needs to be addressed. I think we created this confusion by changing course on the WG. We originally wanted a replacement for k= because of its deficiencies, which we describe in the I-D. We developed some misgivings on this course when working through the O/A, which is very transport specific. It did not seem prudent to define secure transports, O/A, etc. for fax, whiteboard, modem, etc. if we are not planning on testing these specifications on real-world implementations. I guess we are in a bit of a muddle on this important point. Sorry about that. What we feel confident doing here is defining the best possible specification for SRTP. >>>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.) > >I don't see a problem with defining it this way. However there is need to >clearly define that this specification does not cover the case with >multiple m= line for the same port. > >>> 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-? > >Yes, and explanation on how the parameters a=crypto are used for this purpose. I think that a non-zero MKI explains it all. >>>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? > >As SRTP-WINDOW-SIZE is application dependent there might be need for an >application to hint how big this window should be to work satisfactory. >However there might be enough information given in SDP attributes like >a=maxprate and the bandwidth modifiers to allow a receiving side to derive >the parameters. One could allow the parameter as a hint to the application. ok. I think the outstanding problem that we need to resolve with the WG is to what degree we generalize a=crypto beyond the SRTP transport. thanks, Mark >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 Tue Aug 19 12:50: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 MAA22887 for ; Tue, 19 Aug 2003 12:50: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 19p9gL-0006MU-QJ for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 12:50:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGo5XR024448 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 12:50:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9gL-0006MF-Mx for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:50: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 MAA22850 for ; Tue, 19 Aug 2003 12:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9gJ-0003Ve-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 12:50:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9gJ-0003Vb-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 12:50:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9gH-0006Le-SF; Tue, 19 Aug 2003 12:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9fz-0006Ks-Ai for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 12:49:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22826 for ; Tue, 19 Aug 2003 12:49:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9fw-0003Up-00 for mmusic@ietf.org; Tue, 19 Aug 2003 12:49:40 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19p9fv-0003Uh-00 for mmusic@ietf.org; Tue, 19 Aug 2003 12:49:39 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7JGnV7W001655; Tue, 19 Aug 2003 18:49:31 +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 QY1JF6PM; Tue, 19 Aug 2003 18:49:59 +0200 Message-ID: <3F42551B.9010503@ericsson.com> Date: Tue, 19 Aug 2003 18:49:31 +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: Henning Schulzrinne CC: Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility References: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> <3F421099.8010508@ericsson.com> <3F423F29.5030708@cs.columbia.edu> In-Reply-To: <3F423F29.5030708@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Henning & Enrico Yes, I don't see a problem with this. In the updated specification this=20 is the main reason why we maintain and strength the requirement that the = RTSP session shall be independent of the RTSP message transport. Henning, you are probably correct that the it only a few paragraphs to=20 explain how to achieve application layer mobility and that way provide=20 robustness. Unless some one objects I would propose that we add some text on this=20 issue in the RTSP core specification. Cheers Magnus Henning Schulzrinne wrote: > Since this is a source of interoperability problems, some basic=20 > discussions on transport behavior seems helpful for the base spec. You = > can't fix the problems with an additional spec. I don't think this has = > to be complicated, but address changes are now not uncommon for=20 > long-lived sessions (e.g., due to multi-homed hosts, DHCP or moving=20 > around between 802.11 APs.) >=20 > Magnus Westerlund wrote: >=20 >> Hi Enrico, >> >> I have not had time to read the paper by Schulzrinne. However from=20 >> what I understand this should be possible to do in RTSP. However it=20 >> touches upon grey zones in the specification in two ways. The=20 >> connection between RTSP message transport and session, that should not= =20 >> exist. And the usage of SETUP to change transport parameters.=20 >> Therefore I am not surprised that the Darwin server does not work in=20 >> your experiments. >> >> I think the Darwin server connects the TCP connection to the session=20 >> and that the session actually is deleted if the TCP connection is=20 >> removed. >> >> There is no discussion of how to use RTSP for application layer=20 >> mobility. Are there a need for such a chapter in the specification or = >> as a separate draft? >> >> Best Regards >> >> Magnus >> >> Enrico Balatti wrote: >> >>> 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 the=20 >>> 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=20 >>> compliant. >>> >>> Do you know where the RTSP specification talks about the RTSP=20 >>> 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 >>> >>> >>> 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 I= P >>> address changes on the mobile because of subnet movement o= r >>> domain movement. >>> >>> Thanks >>> Ashutosh >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mmusic >>> >> >=20 >=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 Tue Aug 19 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 NAA24290 for ; Tue, 19 Aug 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 19pA8N-0007fU-Nk for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 13:19:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JHJ3tX029470 for mmusic-archive@odin.ietf.org; Tue, 19 Aug 2003 13:19:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pA8N-0007fF-KS for mmusic-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 13:19: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 NAA24248 for ; Tue, 19 Aug 2003 13:18:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pA8L-0003vs-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 13:19:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pA8K-0003vp-00 for mmusic-web-archive@ietf.org; Tue, 19 Aug 2003 13:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pA8L-0007ep-7N; Tue, 19 Aug 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 19pA7Q-0007d0-FS for mmusic@optimus.ietf.org; Tue, 19 Aug 2003 13: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 NAA24231 for ; Tue, 19 Aug 2003 13:18:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pA7O-0003vS-00 for mmusic@ietf.org; Tue, 19 Aug 2003 13:18:02 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19pA7N-0003vL-00 for mmusic@ietf.org; Tue, 19 Aug 2003 13:18:01 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19pA7C-00017X-00; Tue, 19 Aug 2003 10:17:50 -0700 Date: Tue, 19 Aug 2003 10:17:50 -0700 From: Tom Marshall To: Magnus Westerlund Cc: Henning Schulzrinne , Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility Message-ID: <20030819171750.GA3989@real.com> References: <6F5FB8313FE82C4EA10DA4DA40B90949B0658A@swing.cefriel.it> <3F421099.8010508@ericsson.com> <3F423F29.5030708@cs.columbia.edu> <3F42551B.9010503@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <3F42551B.9010503@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: , --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In order to make this work, don't you also need to s/MAY/MUST/ in the first paragraph of 10.4? This would seem to be a controversial change. On Tue, Aug 19, 2003 at 06:49:31PM +0200, Magnus Westerlund wrote: > Hi Henning & Enrico >=20 > Yes, I don't see a problem with this. In the updated specification this= =20 > is the main reason why we maintain and strength the requirement that the= =20 > RTSP session shall be independent of the RTSP message transport. >=20 > Henning, you are probably correct that the it only a few paragraphs to=20 > explain how to achieve application layer mobility and that way provide=20 > robustness. >=20 > Unless some one objects I would propose that we add some text on this=20 > issue in the RTSP core specification. >=20 > Cheers >=20 > Magnus >=20 >=20 >=20 > Henning Schulzrinne wrote: > >Since this is a source of interoperability problems, some basic=20 > >discussions on transport behavior seems helpful for the base spec. You= =20 > >can't fix the problems with an additional spec. I don't think this has= =20 > >to be complicated, but address changes are now not uncommon for=20 > >long-lived sessions (e.g., due to multi-homed hosts, DHCP or moving=20 > >around between 802.11 APs.) > > > >Magnus Westerlund wrote: > > > >>Hi Enrico, > >> > >>I have not had time to read the paper by Schulzrinne. However from=20 > >>what I understand this should be possible to do in RTSP. However it=20 > >>touches upon grey zones in the specification in two ways. The=20 > >>connection between RTSP message transport and session, that should not= =20 > >>exist. And the usage of SETUP to change transport parameters.=20 > >>Therefore I am not surprised that the Darwin server does not work in=20 > >>your experiments. > >> > >>I think the Darwin server connects the TCP connection to the session=20 > >>and that the session actually is deleted if the TCP connection is=20 > >>removed. > >> > >>There is no discussion of how to use RTSP for application layer=20 > >>mobility. Are there a need for such a chapter in the specification or= =20 > >>as a separate draft? > >> > >>Best Regards > >> > >>Magnus > >> > >>Enrico Balatti wrote: > >> > >>>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 the=20 > >>>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=20 > >>>compliant. > >>> > >>>Do you know where the RTSP specification talks about the RTSP=20 > >>>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 > >>> > >>> > >>>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 > >>> > >> > > > > >=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 --=20 Did you ever notice that fat chance and slim chance mean the same thing? --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Qlu+qznSmcYu2m8RAgxXAJ4h4ShizOw3EMjjvsxgiYi2YoITWACgiBPL P4zDTQnI8HippIJ+DetCo8o= =haoO -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Aug 20 03:37: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 DAA27649 for ; Wed, 20 Aug 2003 03:37: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 19pNWi-0006zl-6M for mmusic-archive@odin.ietf.org; Wed, 20 Aug 2003 03:37:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K7b40j026888 for mmusic-archive@odin.ietf.org; Wed, 20 Aug 2003 03:37:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pNWh-0006zb-VZ for mmusic-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 03:37: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 DAA27642 for ; Wed, 20 Aug 2003 03:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pNWf-0005Zp-00 for mmusic-web-archive@ietf.org; Wed, 20 Aug 2003 03:37:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pNWe-0005Zl-00 for mmusic-web-archive@ietf.org; Wed, 20 Aug 2003 03: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 19pNWe-0006xr-CW; Wed, 20 Aug 2003 03:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pNWE-0006wk-4k for mmusic@optimus.ietf.org; Wed, 20 Aug 2003 03:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27595 for ; Wed, 20 Aug 2003 03:36:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pNWB-0005ZD-00 for mmusic@ietf.org; Wed, 20 Aug 2003 03:36:31 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19pNWB-0005Z9-00 for mmusic@ietf.org; Wed, 20 Aug 2003 03:36:31 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h7K7aSgM006472; Wed, 20 Aug 2003 09:36:28 +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 QXY99VCS; Wed, 20 Aug 2003 09:36:52 +0200 Message-ID: <3F4324FB.4070006@ericsson.com> Date: Wed, 20 Aug 2003 09:36:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Henning Schulzrinne , Enrico Balatti , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility References: <20030819171750.GA3989@real.com> In-Reply-To: <20030819171750.GA3989@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, Yes, you are correct that the current MAY would need to be changed to MUST to always allow it. Performing this change may be a bit to much change. I think that it would be better to explain why support of this functionality is good, based on that it makes Application layer mobility possible. If there is need to learn the support for this, we should define a feature tag for it. Is anybody willing to look through the specification to see if there are any more conflicts or limitations and provide a draft informational text about this? Best Regards Magnus Tom Marshall wrote: > In order to make this work, don't you also need to s/MAY/MUST/ in the > first > paragraph of 10.4? This would seem to be a controversial change. > 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 Aug 20 13:06: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 NAA20116 for ; Wed, 20 Aug 2003 13:06: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 19pWPL-0007Lj-IY for mmusic-archive@odin.ietf.org; Wed, 20 Aug 2003 13:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KH631S028250 for mmusic-archive@odin.ietf.org; Wed, 20 Aug 2003 13:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWPL-0007LZ-EN for mmusic-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:06: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 NAA20098 for ; Wed, 20 Aug 2003 13:05:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWPJ-0003ju-00 for mmusic-web-archive@ietf.org; Wed, 20 Aug 2003 13:06:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWPJ-0003jr-00 for mmusic-web-archive@ietf.org; Wed, 20 Aug 2003 13:06:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWPJ-0007L7-Le; Wed, 20 Aug 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWPH-0007Kg-Ca for mmusic@optimus.ietf.org; Wed, 20 Aug 2003 13:05: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 NAA20094 for ; Wed, 20 Aug 2003 13:05:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWPF-0003jo-00 for mmusic@ietf.org; Wed, 20 Aug 2003 13:05:57 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19pWPE-0003jl-00 for mmusic@ietf.org; Wed, 20 Aug 2003 13:05:56 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7KH5U31012191; Wed, 20 Aug 2003 19:05:30 +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 QXYZ1HB0; Wed, 20 Aug 2003 19:05:30 +0200 Message-ID: <3F43AA5A.70107@ericsson.com> Date: Wed, 20 Aug 2003 19:05: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: Mark Baugher CC: Dan Wing , Flemming Andreasen , IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt References: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> In-Reply-To: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.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 Mark More comments below. Mark Baugher wrote: >> Okay, the question is if this is acceptable. As I can see it there are >> two ways when defining "a=crypto" >> >> 1. As a future safe replacement of a=k > > > Do you mean k=? Yes. > > > I think that a=crypto does everything that k= does. My concern is that > there might be an unforeseen need for extension for a particular transport. > Not as currently specified. Can't k= be used to specify the use of DES on complete RTP and RTCP packets? This is certainly something different than what so far is defined. However I don't know if there is any need for including this. > > I suppose it is but it would be a very brittle way to define the crypto > suite, which *may be* orthogonal to the transport. In the first > submission of this work, we expected the crypto suite to be transport > independent. The reason it is not is because we have seen examples of > the crypto suite being tailored and optimized for a particular > transport. For example, AES counter mode for SRTP re-uses the RTP > sequence number to obviate the need to add a nonce to the header and > save precious bits on low bandwidth links. IPsec decided to put a nonce > into the IPsec transport header for AES counter mode - the IV field - > rather than overload the sequence number. For sdescriptions, it seemed > to us to be safer to not try and develop a single set of crypto suites > for all transports since the namespace could become unwieldy (e.g. > AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC). > > You seem to be taking this to its logical conclusion of putting all > transport-specific parameters into the crypto suite, but I don't think > we want to do that. For one thing, it will result in too many crypto > suites. A bigger problem is that some parameter support a range of > values, such as the size of the MKI. What do you mean with transport here? Depending on what level you mean I think that one must in fact make the crypto suits transport dependent. If you with transport means for example RTP and the used profile the crypto suit must in fact be transport dependent as I think your example crypto suits AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC visualize. Even if the same crypto algorithm is used by both SRTP and IPSEC the other parameters are not identical I would assume, or are they? There is need to know that IPSEC should be applied and that SRTP is not needed. Therefore I would assume that the crypto suits must be in fact be dependent on encryption method which might imply certain transports. What we are still discussing in fact are if the a=crypto attribute only should be applicable for SRTP independent on lower layers that transport them, or we should make it possible for future extensions that might apply for usage with other crypto methods? > > >> So the point I try to make is that each crypto suit should define what >> parameters it supports. > > > We made a distinction of parameters that are specific to the key, these > are the domain of the crypto suite, versus parameters related to the > transport, these are the session parameters. > > In fact I would instead say that sessions parameters are SRTP parameters that are not depending on the crypto suit. Are you certain that SEQ/ROC/SSRC is session parameters. I think they would be in fact useless if one develops a crypto suit that are based on explicit IVs instead of the current implicit ones. As a result of that all session parameters are in direct relation to SRTP usage I don't see a problem with tying them to the crypto suit as these crypto suits are directly related SRTP and no other protocol. None of the listed parameters in section 4.3 would care if the RTP is transported over IP/UDP, IP/DCCP, or something completely different as long as the packet borders are recoverable. > > I think we created this confusion by changing course on the WG. We > originally wanted a replacement for k= because of its deficiencies, > which we describe in the I-D. We developed some misgivings on this > course when working through the O/A, which is very transport specific. > It did not seem prudent to define secure transports, O/A, etc. for fax, > whiteboard, modem, etc. if we are not planning on testing these > specifications on real-world implementations. > > I guess we are in a bit of a muddle on this important point. Sorry > about that. What we feel confident doing here is defining the best > possible specification for SRTP. I agree about this. I hope that this message exchange has made it clear to the general public that you would like to change the intention. As this being a WG document you are in fact required or at least strongly encourage to ask the group for input on such changes. I don't think you need to consider all strange, non used methods. However what I think the WG needs to consider is if it should be possible to extend "a=crypto" to carry keys for, DES and 3DES of the complete RTP packet as defined in the RTP spec, or something else that people see need of? If the result of that question is a yes, then I think that the a=crypto attribute must either put in a method indicator first or make the crypto suite carry implicit information about the method and the structure of the rest of the a=crypto line. >>> 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-? >> >> >> Yes, and explanation on how the parameters a=crypto are used for this >> purpose. > > > I think that a non-zero MKI explains it all. > What about the usage of ? I couldn't found anything about it. What I think is important is to resolve how a rekeying with this mechanism will happen. I don't think that the following section actually explains how to perform the rekeying to a point of interoperability. Section 5.7: "When an active SRTP session is rekeyed, this is indicated by sending a new SDP. Rekeying is done following the rules described for a normal Offer/Answer exchange. The Answerer can take this opportunity to rekey the traffic it is sending, if the Answerer desires. During rekeying, the session parameters cannot be changed and MUST NOT be specified in the Offer or the Answer. " I think that you must in fact clarify that the key for rekeying must be connected to a MKI or "from,to" interval to indicate when valid. > ok. I think the outstanding problem that we need to resolve with the WG > is to what degree we generalize a=crypto beyond the SRTP transport. > Agreed, I hope that some other people can give there opinion about this. 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 Aug 21 10:48: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 KAA08549 for ; Thu, 21 Aug 2003 10:48: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 19pqjN-0001yR-28 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 10:48:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LEm5gZ007583 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 10:48:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqjM-0001yE-VE for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 10:48: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 KAA08516 for ; Thu, 21 Aug 2003 10:47:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pqjK-00048r-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 10:48:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pqjJ-00048n-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 10:48:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pqjJ-0001xe-Gp; Thu, 21 Aug 2003 10: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 19pqiq-0001x8-RY for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 10:47: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 KAA08499 for ; Thu, 21 Aug 2003 10:47:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pqio-00048X-00 for mmusic@ietf.org; Thu, 21 Aug 2003 10:47:30 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19pqin-00048T-00 for mmusic@ietf.org; Thu, 21 Aug 2003 10:47:29 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LElR31026090 for ; Thu, 21 Aug 2003 16:47:27 +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 QY1JWGSF; Thu, 21 Aug 2003 16:48:02 +0200 Message-ID: <3F44DB7F.7060208@ericsson.com> Date: Thu, 21 Aug 2003 16:47:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.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] RTSP: The use of the SDP attribute "a=range:" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 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, During the 57th IETF meeting we discussed the meaning of open intervals for the SDP attribute a=range, e.g. "a=range:npt=0-". My memory and notes indicates that the conclusions made was: 1. An open range indicates a media with unknown duration. 2. There seem to be need for more attributes expressing things like: seekability. The start of the discussion on this topic was the usability of an open range to indicate that media is live and not seekable. There where comments that even though a session is live it might be seekable, at least into the past, i.e. behind "now". This is can be accomplished by on the fly recording servers. However there is a lack of possibility to express this capability. There are currently implementations that interpret an open range as not being seekable, for example the quicktime 6.3 player. So to rehash the question in this forum: Would it be acceptable to define an open interval range attribute as being live and non seekable unless other attributes give further properties, like seekable? If you own a commercial implementation of a RTSP client, could you please inform how it would react to an open range? Looking forward to your comments. 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 Thu Aug 21 11:14: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 LAA09549 for ; Thu, 21 Aug 2003 11:14: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 19pr8U-0003I8-Vm for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 11:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LFE2i5012646 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 11:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pr8U-0003Ht-Rq for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 11:14: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 LAA09533 for ; Thu, 21 Aug 2003 11:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pr8T-0004Q2-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 11:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pr8T-0004Px-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 11:14:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pr8S-0003HS-Tn; Thu, 21 Aug 2003 11:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pr7s-0003GQ-HH for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 11:13: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 LAA09493 for ; Thu, 21 Aug 2003 11:13:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pr7r-0004Pb-00 for mmusic@ietf.org; Thu, 21 Aug 2003 11:13:23 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19pr7q-0004PY-00 for mmusic@ietf.org; Thu, 21 Aug 2003 11:13:22 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LFDIAv005040 for ; Thu, 21 Aug 2003 17:13:21 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Aug 2003 17:13:52 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'mmusic@ietf.org'" Date: Thu, 21 Aug 2003 17:13:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="ISO-8859-1" Subject: [MMUSIC] Using static payload types for dynamic codecs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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, This mail is related to an issue which has came up at the SIPit interop event. Page 39 in sdp-new-13 says the following: "RTP payload formats under the "RTP/AVP" protocol that have been assigned static payload types MUST use the static payload type as their "fmt" value. For payload formats under "RTP/AVP" that have a dynamic payload type number, the dynamic payload type number is given as the "fmt" and an additional "rtpmap" attribute specifies registration for the payload format." My question is: is it allowed, when using a dynamic codec, to "override" a static payload type, using rtpmap, for that codec. For example, 0 is the statically defined payload type for PCMU. Now, is the following allowed: m=audio 99999 0 a=rtpmap: 0 DYNAMIC_CODEC/8000 I can't find anywhere in the sdp draft text saying that this is forbidden (I appologise if it's there and I've just missed it), and RFC3551 (chapter 3) doesn't forbid it either, so... Regards, Christer Holmberg Ericsson Finland _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Aug 21 12:07: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 MAA11824 for ; Thu, 21 Aug 2003 12:07: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 19prxs-0005hq-VQ for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 12:07:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LG78Wo021933 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 12:07:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19prxs-0005hg-R7 for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 12:07: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 MAA11757 for ; Thu, 21 Aug 2003 12:07:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19prxr-00052h-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 12:07:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19prxq-00052e-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 12:07:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19prxm-0005g5-5b; Thu, 21 Aug 2003 12: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 19prwy-0005du-DR for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 12:06: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 MAA11629 for ; Thu, 21 Aug 2003 12:06:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19prwx-0004zn-00 for mmusic@ietf.org; Thu, 21 Aug 2003 12:06:11 -0400 Received: from machine77.level3.com ([209.244.4.106] helo=cc26-01.idc1.level3.com) by ietf-mx with esmtp (Exim 4.12) id 19prww-0004yt-00 for mmusic@ietf.org; Thu, 21 Aug 2003 12:06:10 -0400 Received: from cc26-01.idc1.level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id C036B8733A; Thu, 21 Aug 2003 16:05:38 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.7.194]) by cc26-01.idc1.level3.com (Postfix) with SMTP id 82B44858DE; Thu, 21 Aug 2003 16:05:38 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.8.20]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Aug 2003 10:05:38 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Using static payload types for dynamic codecs X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Date: Thu, 21 Aug 2003 10:05:37 -0600 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC013A984@idc1exc0004.corp.global.level3.com> Thread-Topic: [MMUSIC] Using static payload types for dynamic codecs Thread-Index: AcNn+uBmPQmuHk8+Qs6BpnBi5t4yCwAALiyQ From: "Hearty, John" To: "Christer Holmberg (SE/LMF)" , X-OriginalArrivalTime: 21 Aug 2003 16:05:38.0291 (UTC) FILETIME=[0FEADC30:01C367FE] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable This RFC 3551 text seems to answer your question most directly, the last MAY allows it.: 3. Registering Additional Encodings This profile reserves payload type numbers in the range 96-127 exclusively for dynamic assignment. Applications SHOULD first use values in this range for dynamic payload types. Those applications which need to define more than 32 dynamic payload types MAY bind codes below 96, in which case it is RECOMMENDED that unassigned payload type numbers be used first. However, the statically assigned payload types are default bindings and MAY be dynamically bound to new encodings if needed. Redefining payload types below 96 may cause incorrect operation if an attempt is made to join a session without obtaining session description information that defines the dynamic payload types. John > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of > Christer Holmberg (SE/LMF) > Sent: Thursday, August 21, 2003 9:13 AM > To: 'mmusic@ietf.org' > Subject: [MMUSIC] Using static payload types for dynamic codecs >=20 >=20 > Hi, >=20 > This mail is related to an issue which has came up at the SIPit interop > event. >=20 > Page 39 in sdp-new-13 says the following: >=20 > "RTP payload formats under the "RTP/AVP" protocol that have been > assigned static payload types MUST use the static payload type as > their "fmt" value. For payload formats under "RTP/AVP" that have > a dynamic payload type number, the dynamic payload type number is > given as the "fmt" and an additional "rtpmap" attribute specifies > registration for the payload format." >=20 >=20 > My question is: is it allowed, when using a dynamic codec, to "override" a > static payload type, using rtpmap, for that codec. >=20 > For example, 0 is the statically defined payload type for PCMU. Now, is > the following allowed: >=20 > m=3Daudio 99999 0 > a=3Drtpmap: 0 DYNAMIC_CODEC/8000 >=20 > I can't find anywhere in the sdp draft text saying that this is forbidden > (I appologise if it's there and I've just missed it), and RFC3551 (chapter > 3) doesn't forbid it either, so... >=20 > Regards, >=20 > Christer Holmberg > Ericsson Finland >=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 Thu Aug 21 12:24: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 MAA12799 for ; Thu, 21 Aug 2003 12:24: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 19psEG-0006nx-03 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 12:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LGO3wG026156 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 12:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psEF-0006nn-Ss for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 12:24: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 MAA12760 for ; Thu, 21 Aug 2003 12:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19psEE-0005Jp-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 12:24:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19psED-0005Jm-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 12:24:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19psEC-0006mX-Ex; Thu, 21 Aug 2003 12: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 19psDU-0006kq-MY for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 12:23: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 MAA12716 for ; Thu, 21 Aug 2003 12:23:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19psDT-0005Id-00 for mmusic@ietf.org; Thu, 21 Aug 2003 12:23:15 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19psDS-0005IA-00 for mmusic@ietf.org; Thu, 21 Aug 2003 12:23:14 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7LGMWAv016723; Thu, 21 Aug 2003 18:22:32 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 21 Aug 2003 18:23:07 +0200 Message-ID: From: "Christer Holmberg (SE/LMF)" To: "'Hearty, John'" , mmusic@ietf.org Subject: RE: [MMUSIC] Using static payload types for dynamic codecs Date: Thu, 21 Aug 2003 18:22:15 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 John, Yes, RFC 3551 allows it. The question is if SDP allows it. One COULD use SDP for another transport than RTP, so I really think the SDP spec should define if it's allowd or not in SDP. Thanks for your comments! Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Hearty, John [mailto:John.Hearty@Level3.com] > Sent: 21. elokuuta 2003 19:06 > To: Christer Holmberg (SE/LMF); mmusic@ietf.org > Subject: RE: [MMUSIC] Using static payload types for dynamic codecs > > > > This RFC 3551 text seems to answer your question most > directly, the last > MAY allows it.: > > 3. Registering Additional Encodings > > This profile reserves payload type numbers in the range 96-127 > exclusively for dynamic assignment. Applications SHOULD first use > values in this range for dynamic payload types. Those applications > which need to define more than 32 dynamic payload types MAY bind > codes below 96, in which case it is RECOMMENDED that unassigned > payload type numbers be used first. However, the > statically assigned > payload types are default bindings and MAY be dynamically bound to > new encodings if needed. Redefining payload types below > 96 may cause > incorrect operation if an attempt is made to join a session without > obtaining session description information that defines the dynamic > payload types. > > > John > > > > -----Original Message----- > > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf > Of > > Christer Holmberg (SE/LMF) > > Sent: Thursday, August 21, 2003 9:13 AM > > To: 'mmusic@ietf.org' > > Subject: [MMUSIC] Using static payload types for dynamic codecs > > > > > > Hi, > > > > This mail is related to an issue which has came up at the SIPit > interop > > event. > > > > Page 39 in sdp-new-13 says the following: > > > > "RTP payload formats under the "RTP/AVP" protocol that have been > > assigned static payload types MUST use the static payload type as > > their "fmt" value. For payload formats under "RTP/AVP" that have > > a dynamic payload type number, the dynamic payload type number is > > given as the "fmt" and an additional "rtpmap" attribute specifies > > registration for the payload format." > > > > > > My question is: is it allowed, when using a dynamic codec, to > "override" a > > static payload type, using rtpmap, for that codec. > > > > For example, 0 is the statically defined payload type for PCMU. Now, > is > > the following allowed: > > > > m=audio 99999 0 > > a=rtpmap: 0 DYNAMIC_CODEC/8000 > > > > I can't find anywhere in the sdp draft text saying that this is > forbidden > > (I appologise if it's there and I've just missed it), and RFC3551 > (chapter > > 3) doesn't forbid it either, so... > > > > Regards, > > > > Christer Holmberg > > Ericsson Finland > > > > > > > > _______________________________________________ > > 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 Aug 21 14:38: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 OAA21102 for ; Thu, 21 Aug 2003 14:38: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 19puK2-0004pf-9y for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 14:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LIc9uN018539 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 14:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19puK0-0004oN-Fy for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 14:38: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 OAA21086 for ; Thu, 21 Aug 2003 14:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19puJx-0007MY-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 14:38:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19puJx-0007MV-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 14:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19puJv-0004iQ-MS; Thu, 21 Aug 2003 14:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19puJs-0004hM-3k for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 14:38: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 OAA21067 for ; Thu, 21 Aug 2003 14:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19puJp-0007M2-00 for mmusic@ietf.org; Thu, 21 Aug 2003 14:37:57 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19puJo-0007Lt-00 for mmusic@ietf.org; Thu, 21 Aug 2003 14:37:56 -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 h7LIbQ5q015160 for ; Thu, 21 Aug 2003 11:37:26 -0700 (PDT) Received: from jamba (jamba [129.146.124.115]) by phys-ha1mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with SMTP id LAA18443 for ; Thu, 21 Aug 2003 11:37:26 -0700 (PDT) Message-Id: <200308211837.LAA18443@phys-ha1mpka.Eng.Sun.COM> Date: Thu, 21 Aug 2003 11:37:26 -0700 (PDT) From: Geetha Srikantan Reply-To: Geetha Srikantan To: mmusic@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mG1M7JHvtPRPwiRSkSqq/A== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Subject: [MMUSIC] RTSP: draft-ietf-mmusic-rfc2326bis-04 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I meant to send this in earlier..here it is now.. Questions and comments (some typos too): Page 10: Transport Negotiation Can transport parameters of an existing session be changed, mid-stream? For instance, is it possible to change the server's RTP/RTCP ports mid-stream? If so, exactly how does the transition to using the new ports happen? Do some mechanisms need to be specified to ensure synchronization etc after the cutover? If not, it would be good to specify the states in which transport negotiation can be done. Page 10, last paragraph section 1.5 - are 'stream identifiers' the same as 'session identifiers'? If so, it might help to use the same term throughout the document. Page 14, section 2 - typo after last paragraph 'b'? Page 15, 1st paragraph, last sentence - typo? Page 15, 3rd paragraph, it might help to rephrase to say that FQDNs are preferred, especially for IPv6, (maybe even 'required for IPv6 ?) however IP addresses should also be supported (for backward compatibility). Page 18, section 3.7, 2nd sentence - typo 'in' appears twice. Page 20, section 5 - adding Expires header? Page 27, section 7.1.2 - add Expires header? Page 30, section 9.3, 3rd paragraph, last sentence - typo? Page 31, section 9.3, Is play.basic a superset of *not* con.persistent? Page 31, section 9.4, 1st paragraph, 4th sentence s/must/should/? I.e. 'This requires that any RTSP URL pointing tat a IPv6 host should use fully qualified domain name and not a IPv6 address.' Page 31, section 10, 1st paragraph, 2nd sentence - typo 'too'? Page 31-32, section 10, Should responses to OPTIONS be cached? If so, is there an expiry on this and any specification on how to refresh? Are there rules about determining capability in the presence of a proxy? Does this section specify all that is required for each endpoint to determine capability? Page 32, 1st paragraph, last sentence - typo? Should it say 'Public header tag which declares...'? Page 32, 2nd paragraph, typos? Should it be 'It is not necessary to use OPTIONS to discover support of a method, it is possible to simply try it. If the receiver of the request does not support the method it will respond with an error code indicating that the method is either not implemented (501) or does not apply for the resource (405). ..' Page 32, 3rd paragraph, 3rd sentence, typo? Should it be: 'The amount of functionality that a feature-tag represents can vary significantly.' Page 32, 5th paragrapgh, typo? Should it be: 'Supported: The supported header is used..' Page 34, 1st paragraph - typo? "SHOULD NOT" instead of "SHOULD not"? Page 36, section 11.3, 2nd paragraph - the part that mentions that the media shall start to play in sync. Does a=group apply to this discussion? What is the scope of synchronization here - does it mean that packets are sent on the different tracks according the the movie timeline that is specified for all packets in the track? Also, does 'setup.playing' apply to a specific URL or request/session or is it a statement about the server in general? Page 37, 3rd paragraph 'Since SETUP.." Isn't it likely that there would be intermediary devices that would be interested in seeing the b= line in the DESCRIBE response as well? Page 38: liveness: Should there be a mention of signs of liveness - no RTCP and no TCP KeepAlive implies the session is gone? Page 39, 4th paragraph, about the Range header. There is a mention in section 3.5, 2nd paragraph, that 'now' should only be used for live. This applies even in this section, right? I.e. the recommendation to use npt=now- is for live? Page 39, 5th paragraph - If there is no Range header in the request, what should the response use as units for the Range header? There was a suggestion that, if you do have the Range in npt, it can be used, if not in the SETUP response there should be an indication of the Range specifications that apply to the stream. Also, it seems like the specification here is only for old implementations, as newer implementations the Range header must be sent in the request according to Page 41. Page 39, last paragraph - typo? Should it be 'After playing the desired range, the presentation is NOT automatically paused, media delivery simply stops. A PAUSE must be issued before another PLAY request can be issued." Page 41, 2nd and 3rd paragraph: Here it says PLAY without range is not ok - does this apply for stored content only? This seems to contradict the text in the 3rd paragraph.. Page 43, 1st paragraph - is very confusing. Does this refer to the case where the PAUSE request comes after the first occurence? Again it seems like PLAY without a range header is ok...confusing. Page 44, section 11.6, 1st paragraph, suggested rewording of the last few sentences: 'However the session and any other media not torn down yet, remains, and any valid request, e.g. PLAY or SETUP, can be issued. As an optional feature a server MAY keep a session even after the last media on it has been torn down by use of TEARDOWN with a media URI for the last media. In this cases, when the server continues to maintain a valid session, after processing a TEARDOWN request on this session, the server MUST return the session identifier in the TEARDOWN response.' Page 44, section 11.6, last paragraph: It would help to move these sentences to earlier in the section - to explain the motivation for what's discussed in the sentences above. That's it for now, geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Aug 21 17:22: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 RAA01169 for ; Thu, 21 Aug 2003 17: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 19pwsd-0002dc-Cl for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 17:22:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LLM3Be010134 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 17:22:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwsd-0002dN-9N for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 17:22: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 RAA01145 for ; Thu, 21 Aug 2003 17:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwsb-0001yJ-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 17:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pwsa-0001yG-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 17:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pwsb-0002cs-LY; Thu, 21 Aug 2003 17: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 19pwsM-0002cb-6W for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 17:21: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 RAA01139 for ; Thu, 21 Aug 2003 17:21:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pwsJ-0001y6-00 for mmusic@ietf.org; Thu, 21 Aug 2003 17:21:43 -0400 Received: from emblaze.com ([212.68.150.1] helo=embexcil02.emblaze.ent) by ietf-mx with esmtp (Exim 4.12) id 19pwsJ-0001xm-00 for mmusic@ietf.org; Thu, 21 Aug 2003 17:21:43 -0400 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="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [MMUSIC] RTSP: The use of the SDP attribute "a=range:" Date: Fri, 22 Aug 2003 00:23:53 +0300 Message-ID: Thread-Topic: [MMUSIC] RTSP: The use of the SDP attribute "a=range:" Thread-Index: AcNn88RmFQidcg7GQauYlXteeFBmUwANnHEy From: "Amir Wolf" To: "Magnus Westerlund" , "IETF MMUSIC WG" 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 SGkgTWFnbnVzLA0KSW4gdGhlIFBTUyBBRyB3ZSBoYXZlIGJlZW4gdGVzdGluZyBsaXZlIGFzIHBh cnQgb2Ygb3VyIGludGVyb3BlcmFiaWxpdHkgdGVzdHMuDQpUaGUgdmVuZG9ycyB0aGF0IHN1cHBs aWVkIHRoZSBsaXZlIGZlZWRzIChzZXJ2ZXJzKSB1c2VkIGFuIG9wZW4gcmFuZ2UgYXMgYW4gaWRl bnRpZmllciBmb3IgdGhlIGxpbmsgYmVpbmcgYSBsaXZlIGxpbmsuDQpJdCBhcHBlYXJzIHRoYXQg YWxsIHRoZSBjbGllbnRzIGdvdCB0aGUgbWVzc2FnZSBhbmQgdHJlYXRlZCB0aGlzIHNlc3Npb24g YXMgbGl2ZS4gDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBNYWdudXMg V2VzdGVybHVuZCBbbWFpbHRvOm1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0gDQoJU2Vu dDog15QgMjEvMDgvMjAwMyAxNzo0NyANCglUbzogSUVURiBNTVVTSUMgV0cgDQoJQ2M6IA0KCVN1 YmplY3Q6IFtNTVVTSUNdIFJUU1A6IFRoZSB1c2Ugb2YgdGhlIFNEUCBhdHRyaWJ1dGUgImE9cmFu Z2U6Ig0KCQ0KCQ0KDQoJSGksDQoJDQoJRHVyaW5nIHRoZSA1N3RoIElFVEYgbWVldGluZyB3ZSBk aXNjdXNzZWQgdGhlIG1lYW5pbmcgb2Ygb3BlbiBpbnRlcnZhbHMNCglmb3IgdGhlIFNEUCBhdHRy aWJ1dGUgYT1yYW5nZSwgZS5nLiAiYT1yYW5nZTpucHQ9MC0iLiBNeSBtZW1vcnkgYW5kDQoJbm90 ZXMgaW5kaWNhdGVzIHRoYXQgdGhlIGNvbmNsdXNpb25zIG1hZGUgd2FzOg0KCQ0KCTEuIEFuIG9w ZW4gcmFuZ2UgaW5kaWNhdGVzIGEgbWVkaWEgd2l0aCB1bmtub3duIGR1cmF0aW9uLg0KCQ0KCTIu IFRoZXJlIHNlZW0gdG8gYmUgbmVlZCBmb3IgbW9yZSBhdHRyaWJ1dGVzIGV4cHJlc3NpbmcgdGhp bmdzIGxpa2U6DQoJc2Vla2FiaWxpdHkuDQoJDQoJVGhlIHN0YXJ0IG9mIHRoZSBkaXNjdXNzaW9u IG9uIHRoaXMgdG9waWMgd2FzIHRoZSB1c2FiaWxpdHkgb2YgYW4gb3Blbg0KCXJhbmdlIHRvIGlu ZGljYXRlIHRoYXQgbWVkaWEgaXMgbGl2ZSBhbmQgbm90IHNlZWthYmxlLiBUaGVyZSB3aGVyZQ0K CWNvbW1lbnRzIHRoYXQgZXZlbiB0aG91Z2ggYSBzZXNzaW9uIGlzIGxpdmUgaXQgbWlnaHQgYmUg c2Vla2FibGUsIGF0DQoJbGVhc3QgaW50byB0aGUgcGFzdCwgaS5lLiBiZWhpbmQgIm5vdyIuIFRo aXMgaXMgY2FuIGJlIGFjY29tcGxpc2hlZCBieQ0KCW9uIHRoZSBmbHkgcmVjb3JkaW5nIHNlcnZl cnMuIEhvd2V2ZXIgdGhlcmUgaXMgYSBsYWNrIG9mIHBvc3NpYmlsaXR5IHRvDQoJZXhwcmVzcyB0 aGlzIGNhcGFiaWxpdHkuDQoJDQoJVGhlcmUgYXJlIGN1cnJlbnRseSBpbXBsZW1lbnRhdGlvbnMg dGhhdCBpbnRlcnByZXQgYW4gb3BlbiByYW5nZSBhcyBub3QNCgliZWluZyBzZWVrYWJsZSwgZm9y IGV4YW1wbGUgdGhlIHF1aWNrdGltZSA2LjMgcGxheWVyLiBTbyB0byByZWhhc2ggdGhlDQoJcXVl c3Rpb24gaW4gdGhpcyBmb3J1bToNCgkNCglXb3VsZCBpdCBiZSBhY2NlcHRhYmxlIHRvIGRlZmlu ZSBhbiBvcGVuIGludGVydmFsIHJhbmdlIGF0dHJpYnV0ZSBhcw0KCWJlaW5nIGxpdmUgYW5kIG5v biBzZWVrYWJsZSB1bmxlc3Mgb3RoZXIgYXR0cmlidXRlcyBnaXZlIGZ1cnRoZXINCglwcm9wZXJ0 aWVzLCBsaWtlIHNlZWthYmxlPw0KCQ0KCUlmIHlvdSBvd24gYSBjb21tZXJjaWFsIGltcGxlbWVu dGF0aW9uIG9mIGEgUlRTUCBjbGllbnQsIGNvdWxkIHlvdQ0KCXBsZWFzZSBpbmZvcm0gaG93IGl0 IHdvdWxkIHJlYWN0IHRvIGFuIG9wZW4gcmFuZ2U/DQoJDQoJTG9va2luZyBmb3J3YXJkIHRvIHlv dXIgY29tbWVudHMuDQoJDQoJQ2hlZXJzDQoJDQoJTWFnbnVzIFdlc3Rlcmx1bmQNCgkNCglNdWx0 aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWQS9BDQoJLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KCUVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgKzQ2IDggNDA0ODI4 Nw0KCVRvcnNoYW1zZ2F0YW4gMjMgICAgICAgICAgIHwgRmF4ICAgKzQ2IDggNzU3NTU1MA0KCVMt MTY0IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20NCgkNCgkNCgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KCW1tdXNpYyBtYWlsaW5nIGxpc3QNCgltbXVzaWNAaWV0Zi5vcmcNCglodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCgkNCg0K _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Aug 21 18:26: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 SAA06268 for ; Thu, 21 Aug 2003 18:26: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 19pxsc-0005Ta-Na for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 18:26:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7LMQ6lg021044 for mmusic-archive@odin.ietf.org; Thu, 21 Aug 2003 18:26:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pxsc-0005TL-KD for mmusic-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 18:26: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 SAA06235 for ; Thu, 21 Aug 2003 18:25:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pxsZ-0002vh-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 18:26:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pxsY-0002ve-00 for mmusic-web-archive@ietf.org; Thu, 21 Aug 2003 18:26:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pxsY-0005SR-E2; Thu, 21 Aug 2003 18:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pxs2-0005Ra-5m for mmusic@optimus.ietf.org; Thu, 21 Aug 2003 18:25: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 SAA06205 for ; Thu, 21 Aug 2003 18:25:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pxrz-0002uv-00 for mmusic@ietf.org; Thu, 21 Aug 2003 18:25:27 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by ietf-mx with esmtp (Exim 4.12) id 19pxry-0002uO-00 for mmusic@ietf.org; Thu, 21 Aug 2003 18:25:26 -0400 Received: from cscoamera13263.cisco.com (rtp-vpn1-589.cisco.com [10.82.226.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7LMOk4x019802; Thu, 21 Aug 2003 18:24:51 -0400 (EDT) Message-Id: <5.1.1.5.2.20030820124954.051e7608@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 21 Aug 2003 15:24:43 -0700 To: Magnus Westerlund From: Mark Baugher Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt Cc: Dan Wing , Flemming Andreasen , IETF MMUSIC WG In-Reply-To: <3F43AA5A.70107@ericsson.com> References: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , hi Magnus, At 07:05 PM 8/20/2003 +0200, Magnus Westerlund wrote: <...> >>I think that a=crypto does everything that k= does. My concern is that >>there might be an unforeseen need for extension for a particular transport. > >Not as currently specified. Can't k= be used to specify the use of DES on >complete RTP and RTCP packets? This is certainly something different than >what so far is defined. However I don't know if there is any need for >including this. I didn't precisely say what I intended: One can *extend* sdescriptions to do anything that k= does. Adding DES or 3DES, for example, is done by adding a new crypto-suite. >>I suppose it is but it would be a very brittle way to define the crypto >>suite, which *may be* orthogonal to the transport. In the first >>submission of this work, we expected the crypto suite to be transport >>independent. The reason it is not is because we have seen examples of >>the crypto suite being tailored and optimized for a particular >>transport. For example, AES counter mode for SRTP re-uses the RTP >>sequence number to obviate the need to add a nonce to the header and save >>precious bits on low bandwidth links. IPsec decided to put a nonce into >>the IPsec transport header for AES counter mode - the IV field - rather >>than overload the sequence number. For sdescriptions, it seemed to us to >>be safer to not try and develop a single set of crypto suites for all >>transports since the namespace could become unwieldy (e.g. >>AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC). >>You seem to be taking this to its logical conclusion of putting all >>transport-specific parameters into the crypto suite, but I don't think we >>want to do that. For one thing, it will result in too many crypto >>suites. A bigger problem is that some parameter support a range of >>values, such as the size of the MKI. > >What do you mean with transport here? Depending on what level you mean I >think that one must in fact make the crypto suits transport dependent. Sorry, I meant transport (e.g. RTP/SAVP) in the SDP sense, m= . There is really no reason why AES-CM-128-HMAC-SHA1 could not serve multiple transports, in principle, because it uses AES counter mode and HMAC-SHA1, both are standard definitions. But they can diverge: SRTP permits a 128-bit input key for deriving HMAC-SHA1 whereas IPsec requires a 160-bit input, IPsec uses a longer counter, etc. There is no reason why future crypto suites, however, can't have identical definitions. I think that this is preferable. But we can't have identical definitions for the session parameters because we're talking about different SDP transport protocols, e.g. unlike SRTP, IPsec has no notion of a variable-length key index (probably owing to the differences between a kernel and application implementation), and of course no notion of SRTCP which can be encrypted or not encrypted. >If you with transport means for example RTP and the used profile the >crypto suit must in fact be transport dependent as I think your example >crypto suits AES-CTR-128-HMAC-SHA1-80-SRTP, AES-CTR-128-HMAC-SHA1-80-IPSEC >visualize. Even if the same crypto algorithm is used by both SRTP and >IPSEC the other parameters are not identical I would assume, or are they? >There is need to know that IPSEC should be applied and that SRTP is not >needed. Therefore I would assume that the crypto suits must be in fact be >dependent on encryption method which might imply certain transports. > >What we are still discussing in fact are if the a=crypto attribute only >should be applicable for SRTP independent on lower layers that transport >them, or we should make it possible for future extensions that might apply >for usage with other crypto methods? I want sdescriptions to be extensible to other SDP transports. It definitely has to support extension with other crypto methods. >>>So the point I try to make is that each crypto suit should define what >>>parameters it supports. >> >>We made a distinction of parameters that are specific to the key, these >>are the domain of the crypto suite, versus parameters related to the >>transport, these are the session parameters. >> >>put in a method indicator first or make the crypto suite carry implicit >>information about the method and the structure of the rest of the >>a=crypto line. > > >>>>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-? >>> >>> >>>Yes, and explanation on how the parameters a=crypto are used for this >>>purpose. >> >>I think that a non-zero MKI explains it all. > >What about the usage of ? I couldn't found anything about it. >What I think is important is to resolve how a rekeying with this mechanism >will happen. This can be done with the current definitions based on the sequence number, MKI, and lifetime. >I don't think that the following section actually explains how to perform >the rekeying to a point of interoperability. > >Section 5.7: > "When an active SRTP session is rekeyed, this is indicated by sending > a new SDP. Rekeying is done following the rules described for a > normal Offer/Answer exchange. The Answerer can take this > opportunity to rekey the traffic it is sending, if the Answerer > desires. During rekeying, the session parameters cannot be changed > and MUST NOT be specified in the Offer or the Answer. " > >I think that you must in fact clarify that the key for rekeying must be >connected to a MKI or "from,to" interval to indicate when valid. I think Dan, Flemming and I need to discuss this further. >>ok. I think the outstanding problem that we need to resolve with the WG >>is to what degree we generalize a=crypto beyond the SRTP transport. > >Agreed, I hope that some other people can give there opinion about this. I hope so too. As it stands now, this I-D is a framework for all transports but with definitions only for SRTP. We feel we can generalize O/A for all transports. But the session parameters are SRTP only as are the cryptographic-key parameters. If this is okay with the WG, then there is no problem for us. Thanks, Mark >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 Fri Aug 22 02:46: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 CAA07366 for ; Fri, 22 Aug 2003 02:46: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 19q5gV-0001UM-CV for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 02:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M6k792005721 for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 02:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5gU-0001U8-S1 for mmusic-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 02:46: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 CAA07335 for ; Fri, 22 Aug 2003 02:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5gR-0007cb-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 02:46:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q5gQ-0007cY-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 02:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5gP-0001TQ-NM; Fri, 22 Aug 2003 02:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5fc-0001Pr-Qe for mmusic@optimus.ietf.org; Fri, 22 Aug 2003 02:45: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 CAA07308 for ; Fri, 22 Aug 2003 02:45:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5fZ-0007cC-00 for mmusic@ietf.org; Fri, 22 Aug 2003 02:45:09 -0400 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 19q5fY-0007bR-00 for mmusic@ietf.org; Fri, 22 Aug 2003 02:45:08 -0400 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 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 22 Aug 2003 08:46:34 +0200 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949BBE1F1@swing.cefriel.it> Thread-Topic: [MMUSIC] RTSP and mobility Thread-Index: AcNm7kL4DPCaAECKTEWn7UMrm5u9PQBiLrnA 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 Hi Magnus, Tom, Henning and Ashutosh, I agree with you about some "Application Mobility" paragraphs=20 in the RTSP core specification and I also agree on the change=20 from MAY to MUST in section 10.4. According to other commitments, I'll try to look through the = specification=20 searching any more conflicts or limitations. Best Regards, Enrico -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: mercoled=EC 20 agosto 2003 9.36 To: Tom Marshall Cc: Henning Schulzrinne; Enrico Balatti; mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility Hi Tom, Yes, you are correct that the current MAY would need to be changed to=20 MUST to always allow it. Performing this change may be a bit to much=20 change. I think that it would be better to explain why support of this=20 functionality is good, based on that it makes Application layer mobility = possible. If there is need to learn the support for this, we should=20 define a feature tag for it. Is anybody willing to look through the specification to see if there are = any more conflicts or limitations and provide a draft informational text = about this? Best Regards Magnus Tom Marshall wrote: > In order to make this work, don't you also need to s/MAY/MUST/ in the > first > paragraph of 10.4? This would seem to be a controversial change. >=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 Fri Aug 22 03:00: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 DAA07758 for ; Fri, 22 Aug 2003 03:00: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 19q5u5-0002By-Pq for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 03:00:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M709ln008420 for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 03:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5u5-0002Bg-51 for mmusic-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 03:00: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 DAA07725 for ; Fri, 22 Aug 2003 03:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5u1-0007kA-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 03:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q5u0-0007k7-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 03:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5u2-00029v-9t; Fri, 22 Aug 2003 03:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5tZ-00028Y-8x for mmusic@optimus.ietf.org; Fri, 22 Aug 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 CAA07678 for ; Fri, 22 Aug 2003 02:59:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5tV-0007jU-00 for mmusic@ietf.org; Fri, 22 Aug 2003 02:59:33 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 19q5tU-0007jR-00 for mmusic@ietf.org; Fri, 22 Aug 2003 02:59:32 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M6wQ31023846; Fri, 22 Aug 2003 08:58:26 +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 QXYZQR87; Fri, 22 Aug 2003 08:58:26 +0200 Message-ID: <3F45BF0F.8040702@ericsson.com> Date: Fri, 22 Aug 2003 08:58: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: Mark Baugher CC: Dan Wing , Flemming Andreasen , IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt References: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030820124954.051e7608@mira-sjc5-6.cisco.com> In-Reply-To: <5.1.1.5.2.20030820124954.051e7608@mira-sjc5-6.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 Mark, To try to summarize the last mails in the discussion: 1. You are going to create a framework that may be used in the future also for other transports then RTP/SAVP. However you will only define crypto suits that apply for RTP/SAVP. 2. There is need to resolve how "a=crypto" is used for doing rekeying in a synchronized way. 3. Input from others on these issues (especially the first) are desired. I have some comments upon the first thing. I think that this intention is a good one. In respect to the last version I think there are some work on clarifying how this will be done. The big issue that needs to be resolved is: - How to connect a crypto suit to transport? Either you need to define a crypto suit for each transport, or in cases where there might be multiple transport that can use the crypto suit ensure that the transport context will be enough to resolve this. 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 Fri Aug 22 03:07: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 DAA08077 for ; Fri, 22 Aug 2003 03:07: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 19q60n-0002XG-VX for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 03:07:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7M775M8009717 for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 03: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 19q60l-0002WP-Uw for mmusic-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 03:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08060 for ; Fri, 22 Aug 2003 03:06:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q60h-00000G-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 03:06:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19q60h-00000D-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 03:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q60j-0002VV-UO; Fri, 22 Aug 2003 03:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19q5zt-0002T7-Fw for mmusic@optimus.ietf.org; Fri, 22 Aug 2003 03:06: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 DAA07997 for ; Fri, 22 Aug 2003 03:06:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19q5zp-0007n6-00 for mmusic@ietf.org; Fri, 22 Aug 2003 03:06:05 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19q5zo-0007n3-00 for mmusic@ietf.org; Fri, 22 Aug 2003 03:06:04 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7M763Av022783; Fri, 22 Aug 2003 09:06: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 Q9LMSWHN; Fri, 22 Aug 2003 09:06:03 +0200 Message-ID: <3F45C0D9.1090804@ericsson.com> Date: Fri, 22 Aug 2003 09:06: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: Enrico Balatti CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP and mobility References: <6F5FB8313FE82C4EA10DA4DA40B90949BBE1F1@swing.cefriel.it> In-Reply-To: <6F5FB8313FE82C4EA10DA4DA40B90949BBE1F1@swing.cefriel.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Enrico, Enrico Balatti wrote: > Hi Magnus, Tom, Henning and Ashutosh, > > I agree with you about some "Application Mobility" paragraphs > in the RTSP core specification and I also agree on the change > from MAY to MUST in section 10.4. Please not jump ahead of things. Any change of this MAY to a MUST is in need of more extended discussion and consideration. I think I am against changing this due to backwards compatibility reasons. If we would change it and a updated client assumes that all server support this functionality, while all ones does not, it will create problems. In my opinion the most reasonable solution of this problem is to clearly motivate why you should implement this functionality. This can be done in a satisfactory way by creating a application mobility section. To ensure that a client can determine the servers support of the mobility features a feature tag to use in supported header can be defined. That way the client can determine if it will work before attempting it. > > According to other commitments, I'll try to look through the specification > searching any more conflicts or limitations. Very Good! 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 Fri Aug 22 09:03: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 JAA21629 for ; Fri, 22 Aug 2003 09:03: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 19qBZH-0000zn-5l for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 09:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7MD33f3003821 for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 09:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBZH-0000zY-1l for mmusic-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 09: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 JAA21614 for ; Fri, 22 Aug 2003 09:02:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qBZF-0003VK-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 09:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qBZE-0003VH-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 09:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qBZF-0000z8-H1; Fri, 22 Aug 2003 09: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 19qBYl-0000yn-Q0 for mmusic@optimus.ietf.org; Fri, 22 Aug 2003 09:02: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 JAA21610 for ; Fri, 22 Aug 2003 09:02:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qBYk-0003VD-00 for mmusic@ietf.org; Fri, 22 Aug 2003 09:02:30 -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 19qBYj-0003V0-00 for mmusic@ietf.org; Fri, 22 Aug 2003 09:02:29 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 22 Aug 2003 06:01:59 -0700 Received: from cisco.com (sjc-vpn4-861.cisco.com [10.21.83.92]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h7MD1ui1009022; Fri, 22 Aug 2003 06:01:56 -0700 (PDT) Message-ID: <3F461443.F6A5A81A@cisco.com> Date: Fri, 22 Aug 2003 09:01:55 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: Mark Baugher , Dan Wing , IETF MMUSIC WG Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdescription-01.txt References: <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030819084733.052cb3e0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030820124954.051e7608@mira-sjc5-6.cisco.com> <3F45BF0F.8040702@ericsson.com> 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 Magnus Westerlund wrote: > Hi Mark, > > To try to summarize the last mails in the discussion: > > 1. You are going to create a framework that may be used in the future > also for other transports then RTP/SAVP. However you will only define > crypto suits that apply for RTP/SAVP. > We probably need to elaborate on this one a bit: The original intent with the draft was to define a mechanism that can be used to describe and negotiate (using offer/answer) SRTP parameters for SRTP media streams. As always, it is desirable to define a general mechanism to do this rather than just a specific one, however I do have some concerns about scope explosion here as we are not trying to define a mechanism that can be used to negotiate security parameters for any kind of stream, e.g. establish a TLS session or setup an IPSec SA. If it turns out the mechanism can be used to do that, then great, however this in itself should not be a goal. I think a reasonable constraint is that the security parameters must either be such they than just be advertised (e.g. for SAP) or they can be negotiated in a single offer/answer exchange. Anything that doesn't fit within those constraints is out of scope. As far as the security mechanisms are concerned, we need to make a distinction between: 1. The "method" being used for security and any parameters associated with that 2. The crypto-suites being used and any parameters associated with that. By method, I mean for example SRTP, RFC 3550 Section 9, etc. Not all methods can be used with all transports, for example RFC 3550 Section 9 cannot be used for RTP/SAVP, but there could conceivably be more than one method used for a particular transport. Where negotiation is involved, it would be desirable to be able to specify different methods, at least for the initial offer/answer exchange. For subsequent offer/answer exchanges it could be more complicated as the media stream packets themselves may not necessarily have an indication of which method is being used and a graceful switchover thus becomes complicated (unless you use a different port). The crypto-suites will be interpreted within the context of a method (as you indicated earlier) and will have certain parameters associated with them. Going back to offer/answer, we can probably come up with a set of generic rules that apply to all methods and crypto-suites, however I suspect that for most, there will be a need to further define method-specific and maybe even crypto-suite-specific offer/answer rules, with SRTP being one such case. Thus, the draft will define a framework for advertising and negotiating security parameters and provides the details for how to do it for SRTP, but in order to use it for anything other than SRTP, additional specification would be needed (in a seperate RFC). How does this sound ? > > 2. There is need to resolve how "a=crypto" is used for doing rekeying in > a synchronized way. > Agreed. > > 3. Input from others on these issues (especially the first) are desired. > > I have some comments upon the first thing. I think that this intention > is a good one. In respect to the last version I think there are some > work on clarifying how this will be done. The big issue that needs to be > resolved is: > - How to connect a crypto suit to transport? I think crypto-suites should be defined within the context of the method (which includes transport). > Either you need to define a > crypto suit for each transport, or in cases where there might be > multiple transport that can use the crypto suit ensure that the > transport context will be enough to resolve this. > I prefer being explicit and defining it for each method/transport; it also makes the name space issue a lot cleaner. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Aug 22 23:39: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 XAA06582 for ; Fri, 22 Aug 2003 23: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 19qPFG-0007Hm-LC for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 23:39:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7N3dIoe027994 for mmusic-archive@odin.ietf.org; Fri, 22 Aug 2003 23:39:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qPFF-0007HR-4w for mmusic-web-archive@optimus.ietf.org; Fri, 22 Aug 2003 23:39: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 XAA06568 for ; Fri, 22 Aug 2003 23:39:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qPFC-0005MA-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 23:39:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19qPFC-0005M6-00 for mmusic-web-archive@ietf.org; Fri, 22 Aug 2003 23: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 19qPF2-0007E0-Nn; Fri, 22 Aug 2003 23:39:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qPEs-0007Cu-7u for mmusic@optimus.ietf.org; Fri, 22 Aug 2003 23:38: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 XAA06532 for ; Fri, 22 Aug 2003 23:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qPEp-0005L7-00 for mmusic@ietf.org; Fri, 22 Aug 2003 23:38:51 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19qPEo-0005L4-00 for mmusic@ietf.org; Fri, 22 Aug 2003 23:38:50 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 22 Aug 2003 20:26:39 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Fri, 22 Aug 2003 20:26:38 -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; Fri, 22 Aug 2003 20:35:11 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 19qPBs-0002bN-00 for ; Fri, 22 Aug 2003 20:35:48 -0700 Date: Fri, 22 Aug 2003 20:34: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=-2.0 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 #85 - 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-792973 ] Clarify changing of transport parameters (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 22 Aug 2003 00:21:19 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-792973 ] Clarify changing of transport parameters Bugs item #792973, was opened at 2003-08-22 09:21 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=792973&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 changing of transport parameters Initial Comment: The use of SETUP during a session to change the transprot parameters should be clarified in several aspects: - Clarify the text about in which states one can do it. Also the result of failed requests impact, etc. - Clarify the adavantage of this by adding a application mobility section as motiviation. - consider if a feature tag for this is necessary? - Consider if there are any problems of allowing all parameters to be changed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=792973&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 Aug 27 02: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 CAA22504 for ; Wed, 27 Aug 2003 02: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 19rtgv-0002in-QP for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 02:22:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6LxpG010430 for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 02:21:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rrXu-0002Fn-Cy for mmusic-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 00:04: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 AAA16200 for ; Wed, 27 Aug 2003 00:04:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rrXr-0003Nv-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 00:04:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rrXr-0003Ns-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 00:04:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmoq-0005C3-TQ; Tue, 26 Aug 2003 19:01:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rd5a-0002Ba-1U for mmusic@optimus.ietf.org; Tue, 26 Aug 2003 08:38: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 IAA01610 for ; Tue, 26 Aug 2003 08:38:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rd5Y-0000GP-00 for mmusic@ietf.org; Tue, 26 Aug 2003 08:38:20 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 19rd5X-0000GL-00 for mmusic@ietf.org; Tue, 26 Aug 2003 08:38:19 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h7QCcIAv010798; Tue, 26 Aug 2003 14:38:18 +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 Q9LNX2NR; Tue, 26 Aug 2003 14:38:17 +0200 Message-ID: <3F4B54B7.2040707@ericsson.com> Date: Tue, 26 Aug 2003 14:38:15 +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: draft-ietf-mmusic-rfc2326bis-04 References: <200308211837.LAA18443@phys-ha1mpka.Eng.Sun.COM> In-Reply-To: <200308211837.LAA18443@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, And thanks for the review. I have fixed the typos, however there are a few things that may need discussion. If you are replying to any particular section could you please remove everything except that topic and change the subject. Please also one topic per email. Geetha Srikantan wrote: > I meant to send this in earlier..here it is now.. > > Questions and comments (some typos too): > > Page 10: Transport Negotiation > Can transport parameters of an existing session be changed, mid-stream? > For instance, is it possible to change the server's RTP/RTCP ports > mid-stream? Yes, If the server implements it and allows it. As seen by the application mobility discussion this functionality can be used for this. > If so, exactly how does the transition to using the new ports happen? Do some > mechanisms need to be specified to ensure synchronization etc after the cutover? Upon the successful response to a SETUP request to change the transport parameters the server will start using the new parameters. The client to avoid losing any packets should keep the old ports/transport open for a couple of seconds. The client should also have opened its ports for the new transport prior to sending the request. So I don't believe there are any synchronization problem. > If not, it would be good to specify the states in which transport negotiation > can be done. This is currently specified in the state machine. If supported is must be possible in READY state, and MAY be supported in PLAY state. This can probably be a clarified and simplified by tightening the requirements a bit. The text in section 11.3 can probably be improved to be more clear about what is allowed in this respect. > > Page 10, last paragraph section 1.5 - are 'stream identifiers' the > same as 'session identifiers'? If so, it might help to use the same > term throughout the document. In some sense. The occurrence here of stream identifiers should probably be replaced by session ID and stream and control URLs. > > Page 14, section 2 - typo after last paragraph 'b'? Definitely, probably a result of the document generation. > > Page 15, 1st paragraph, last sentence - typo? Definitely a bad sentence. Is now corrected. > > Page 15, 3rd paragraph, it might help to rephrase to say that FQDNs > are preferred, especially for IPv6, (maybe even 'required for IPv6 ?) > however IP addresses should also be supported (for backward > compatibility). I think we have a good level now. First of all the requirement to use FQDNs to handle IPv6 hosts only applies to RFC 2326 servers, not the ones in accordance with this specification. There are also reasons why one might use literal IP addresses. For example in destination fields, a FQDN name that resolve only to the targeted host may not exist. Also there are some performance issues if proxies needs to do DNS requests for all messages it is forwarding. > > Page 18, section 3.7, 2nd sentence - typo 'in' appears twice. Fixed > > Page 20, section 5 - adding Expires header? > Page 27, section 7.1.2 - add Expires header? The Expires header is a Entity header, see section 8. > > Page 30, section 9.3, 3rd paragraph, last sentence - typo? Fixed > Page 31, section 9.3, Is play.basic a superset of *not* con.persistent? play.basic is not a superset of con.peristent. A RTSP entity supporting play.basic must handle non-persistent connections. The con.peristent is defined to allow any service requiring a persistent connection to use this in a Required header. However looking at this I would in fact propose that this is removed. I can't see any clear need and therefore it is unnecessary, and if it is need in the future it can simply be define in relation to the necessary user of the feature tag. > > Page 31, section 9.4, 1st paragraph, 4th sentence s/must/should/? > I.e. 'This requires that any RTSP URL pointing tat a IPv6 host should > use fully qualified domain name and not a IPv6 address.' > It is a informal must, not a normative one. This paragraph is only for information on how to make this work if the other party does not support the updated specification. Are there any problem with this? > Page 31, section 10, 1st paragraph, 2nd sentence - typo 'too'? Fixed > > Page 31-32, section 10, > Should responses to OPTIONS be cached? Maybe, it is actually a problem of what OPTIONS is used for. As long it is only used for determine server capability it is not a problem. However if it is used to maintain session liveness, i.e. session ID present, no. Also depending on the URI and the possibilities to cache ma y vary. Needs further consideration. If so, is there an expiry on > this and any specification on how to refresh? This is a tough problem. I don't think there are. The Expires header is an entity header, but the text in RFC 2616 seems to mean the whole request. SO this is something that needs consideration. > Are there rules about determining capability in the presence of a > proxy? Yes, I would say so. Options can either be targeted at the next hop. Or to the server by including host name. However I think the usage of supported header will not reveal anything about the proxy. Also something that might need some more consideration. > Does this section specify all that is required for each endpoint to > determine capability? Actually this section is totally informal. The specification of the operations is actually dispersed around the document. See the options method and the headers for specification. > > Page 32, 1st paragraph, last sentence - typo? Should it say 'Public > header tag which declares...'? Yes, fixed. > > Page 32, 2nd paragraph, typos? Should it be > 'It is not necessary to use OPTIONS to discover support of a method, > it is possible to simply try it. If the receiver of the request does > not support the method it will respond with an error code indicating > that the method is either not implemented (501) or does not apply for > the resource (405). ..' > Yes, fixed. > Page 32, 3rd paragraph, 3rd sentence, typo? Should it be: > 'The amount of functionality that a feature-tag represents can vary > significantly.' Yes, fixed. > > Page 32, 5th paragrapgh, typo? Should it be: > 'Supported: The supported header is used..' Yes, fixed. > > Page 34, 1st paragraph - typo? "SHOULD NOT" instead of "SHOULD not"? Yes, fixed. > > Page 36, section 11.3, 2nd paragraph - the part that mentions that the > media shall start to play in sync. This is only intended to resolve the synchronization problem when doing SETUP in PLAY state. The newly setuped media must be playing in synch with already present media, otherwise this would break the aggregation policy we apply. > Does a=group apply to this discussion? I have not considered if a=group has any impact at all. I would not thinks so, because such a SETUP as described in the second paragraph in it self requires that the server plays out the media in synch. > What is the scope of synchronization here - does it mean that packets > are sent on the different tracks according the the movie timeline that > is specified for all packets in the track? The session has an internal clock that runs during play state. When a media is added to the session that media must also play out according to that clock. 0----5----10---15---20---25 Session playout time 0xxxx5xxxx10xxx15xxx20xxx25 First media stream 10***15***20***25 Second media stream starts at 10 seconds into the media. In this example a SETUP request to add a second media stream is received at time 10. Then the second media will start playout from time point 10. I hope this clarifies this. Are there need to improve the text in that chapter? Is the functionality (SETUP during PLAY state) needed, or could we throw it away. In my opinion it is not a really necessary and such a extension could anyway be added later. In my eyes it will anyway need extensions. > > Also, does 'setup.playing' apply to a specific URL or request/session > or is it a statement about the server in general? A Feature tag is used in a context, depending on the context it can either relate to a session, media stream, or the complete server. > > Page 37, 3rd paragraph 'Since SETUP.." Isn't it likely that there > would be intermediary devices that would be interested in seeing the > b= line in the DESCRIBE response as well? This is probably something the original authors should answer on. However in my opinion the design is made to allow an middle box to understand that the individual flows exist and which protocols they use. It is not designed to allow for conveying QoS properties for the stream. Anyway I don't think that b= is of much more use then to provide some basic limits. A media stream today is not of fixed bit-rate, it may very well be adapted to available resources for best effort traffic. For streams with QoS agreements they will have there own policy on policing, control and admission control that does not belong in RTSP. > > Page 38: liveness: > Should there be a mention of signs of liveness - no RTCP and no TCP > KeepAlive implies the session is gone? How do you interpret the second last paragraph and bullet list of section 11.3? There are also a reference to section 13.37 that discuss this further. From the text of section 11.3: "Signs of liveness for a RTSP session are: + Any RTSP request from a client which includes a Session header with that session's ID. + If RTP is used as a transport for the underlying media streams, an RTCP sender or receiver report from the client for any of the media streams in that RTSP session." > > Page 39, 4th paragraph, about the Range header. There is a mention > in section 3.5, 2nd paragraph, that 'now' should only be used for > live. This applies even in this section, right? I.e. the > recommendation to use npt=now- is for live? Yes. Is it not understandable that this sentence is in relation to the context of the previous sentence? Have you proposal for improvements of the text? > > Page 39, 5th paragraph - If there is no Range header in the request, > what should the response use as units for the Range header? > There was a suggestion that, if you do have the Range in npt, it can > be used, if not in the SETUP response there should be an indication of > the Range specifications that apply to the stream. Yes, this is a bit unclear. I propose it to clarify it in the following way: For a on-demand stream, the server {\MUST} reply with the actual range that will be played back. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. If no range is specified in the request, the start position {\SHALL} still be returned in the reply. The unit of the range in the reply {\SHOULD} be the same as that in the request. If no range header was present in the request the server {\MAY} use any of the supported formats, however it is {\RECOMMENDED} that a format the client has shown support for is used. If the media part of an aggregate has different lengths the {\PLAY} request and any \header{Range} {\SHALL} be performed as long it is valid for the longest media. Media will be sent whenever it is available for the given play-out point. > > Also, it seems like the specification here is only for old > implementations, as newer implementations the Range header must be > sent in the request according to Page 41. No, it is for the updated specification. There is no requirement that a client includes a range header in a request. The range header MUST be present in responses. Please quote the section you have interpreted as requiring Range in PLAY requests. > > > Page 39, last paragraph - typo? Should it be > 'After playing the desired range, the presentation is NOT > automatically paused, media delivery simply stops. A PAUSE must be > issued before another PLAY request can be issued." Yes, type except that I would like to keep "request" in the last sentence after pause: "A PAUSE request must be issued before another PLAY request can be issued." > > Page 41, 2nd and 3rd paragraph: Here it says PLAY without range is not > ok - does this apply for stored content only? This seems to contradict > the text in the 3rd paragraph.. My intention with the two following paragraphs: "The queued play functionality described in RFC 2326 [21] is removed and multiple ranges can be used to achieve a similar performance. If a server receives a PLAY request while in the PLAY state, the server SHALL respond using the error code 455 (Method Not Valid In This State). This will signal the client that queued play are not sup- ported. The use of PLAY for keep-alive signaling, i.e. PLAY request without a range header, has also been depreciated. Instead a client can use, PING, SET_PARAMETER or OPTIONS for keep alive. A server receiving a PLAY keep alive SHALL respond with the 455 error code." Is that it is informs that while in PLAY state, a PLAY request is not allowed. This was in RFC 2326 used for two different purposes depending on if range was present or not (queued play, and keep alive). These two paragraphs try to explain what to do if one would receive a request that tries to perform such an operation. I will add a "in PLAY state" to the second paragraphs first sentence to be clearer. > > Page 43, 1st paragraph - is very confusing. Does this refer to the > case where the PAUSE request comes after the first occurence? Again it > seems like PLAY without a range header is ok...confusing. I guess it is not that confusing clearing out the previous confusion. > > Page 44, section 11.6, 1st paragraph, suggested rewording of the last > few sentences: > > 'However the session and any other media not torn down yet, remains, > and any valid request, e.g. PLAY or SETUP, can be issued. As an > optional feature a server MAY keep a session even after the last media > on it has been torn down by use of TEARDOWN with a media URI for the > last media. In this cases, when the server continues to maintain a > valid session, after processing a TEARDOWN request on this session, the > server MUST return the session identifier in the TEARDOWN response.' > Yes, you where correct that the sentences need to be reworded. However I was not completely happy with your proposal either. So I propose the following: The {\TEARDOWN} request stops the stream delivery for the given URI, freeing the resources associated with it. If the URI is the aggregated control URI for this presentation, any RTSP session identifier associated with the session is no longer valid. The use of "*" as URI in {\TEARDOWN} will also result in that the session is removed independent of the number of media that was part of it. If the URI in the request was for a media within an aggregated session that media is removed from the aggregate. However the session and any other media not torn down yet, remains, and any valid request, e.g. PLAY or SETUP, can be issued. The server {\MAY} keep the session when the last media is torn down with a {\TEARDOWN} request specifying the media URI. The server {\SHALL} always include in a {\TEARDOWN} response the session header, if a valid session state exist after the processing of the request. However I have logged a bug suggesting that we remove the Ready-NM state. That way we can get rid of the "*" teardowns that I feel will not work satisfactory through proxies. > Page 44, section 11.6, last paragraph: It would help to move these > sentences to earlier in the section - to explain the motivation for > what's discussed in the sentences above. I don't think this provides any motivation. However it might be beneficial to change the the complete section into something that is more readable and more clearly explains things. One can also discuss the need for having TEARDOWN during PLAY state. Please provide input on this topic. 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 Aug 27 02:41: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 CAA27028 for ; Wed, 27 Aug 2003 02:41: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 19rspW-0006mE-6N for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 01:26:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R5QmGn026037 for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 01:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rpeS-00056X-Jo for mmusic-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 22:03: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 WAA04850 for ; Tue, 26 Aug 2003 22:03:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rpeP-0000Zm-00 for mmusic-web-archive@ietf.org; Tue, 26 Aug 2003 22:03:09 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rpeO-0000Zi-00 for mmusic-web-archive@ietf.org; Tue, 26 Aug 2003 22:03:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmfI-0004el-2U; Tue, 26 Aug 2003 18:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19qDLc-0006vk-00 for mmusic@optimus.ietf.org; Fri, 22 Aug 2003 10:57: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 KAA01075; Fri, 22 Aug 2003 10:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19qDLY-0005Vq-00; Fri, 22 Aug 2003 10:57:00 -0400 Received: from terra.inf.ufsc.br ([150.162.60.10]) by ietf-mx with esmtp (Exim 4.12) id 19qDLX-0005VT-00; Fri, 22 Aug 2003 10:57:00 -0400 Received: from localhost (localhost [127.0.0.1]) by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 6695F1A5D4; Fri, 22 Aug 2003 11:56:24 -0300 (BRT) Received: from marte (marte.inf.ufsc.br [150.162.60.7]) by terra.inf.ufsc.br (Departamento de Informatica e Estatistica (INE/CTC/UFSC)) with ESMTP id 1476A1672E; Fri, 22 Aug 2003 11:56:22 -0300 (BRT) Date: Fri, 22 Aug 2003 11:57:25 -0300 (EST) From: Carlos Becker Westphall X-X-Sender: westphal@marte To: Undisclosed recipients: ; Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS 0.3.12pre5 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [MMUSIC] [ieee-cnom] LANOMS'03 - Call for Participation (fwd) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 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 * Apologies if you receive multiple copies of this announcement * LANOMS'03 3rd Latin American Network Operations and Management Symposium Iguassu Falls, Brazil September 4-6, 2003 IEEE ComSoc CNOM Technically Co-sponsored http://www.inf.ufpr.br/lanoms CALL FOR PARTICIPATION ---------------------- Registration is now open. Please register soon: there is a limit of 150 participants. Preliminary Program is now available at: http://www.inf.ufpr.br/lanoms/program.shtml Invited Talks: Evolution of IP/eBusiness Management - New Paradigm and SLA Masayoshi Ejiri, Fujitsu, Japan Management Challenges in an on demand environment Germ=E1n Goldszmidt, IBM, U.S.A. Integrating Latin American and European Research and Education Networks through the Alice Project Michael Stanton, RNP, Brazil Tutorials: Security and Mobility Management in the Embedded Internet Guy Pujole, Universite de Versailles, France Management for Next Generation of Wireless Networks and Services Mehmet Ulema, Manhattan College, New York, U.S.A. Over-the-air Device Management Paul Oommen, Nokia Research Center, U.S.A. Technical Sessions: Security Management Management of Mobile/Wireless and Ad-Hoc Networks Management Platforms and Frameworks Management of Networks and Services Network and Systems Monitoring Management of Service Level Agreements and Quality of Service The symposium will have only single-track Technical Sessions. Details can be found at: http://www.inf.ufpr.br/lanoms/technical_sessions.shtml ---------------------------------------------------------------------- CNOM mailing list CNOM@lrg.ufsc.br http://www.lrg.ufsc.br/mailman/listinfo/cnom _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Aug 28 00:11: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 AAA13037 for ; Thu, 28 Aug 2003 00:11: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 19sBtd-0007Bs-8V for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 21:48:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S1mLtt027636 for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 21:48:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6iw-0006KZ-JB for mmusic-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 16:16: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 QAA04952 for ; Wed, 27 Aug 2003 16:16:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6iu-0007US-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 16:16:56 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s6iu-0007UP-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 16:16:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4w0-00019s-1O; Wed, 27 Aug 2003 14:22:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rr5J-00010r-98 for mmusic@optimus.ietf.org; Tue, 26 Aug 2003 23: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 XAA13254 for ; Tue, 26 Aug 2003 23:34:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rr5H-0002gh-00 for mmusic@ietf.org; Tue, 26 Aug 2003 23:34:59 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 19rr5G-0002gZ-00 for mmusic@ietf.org; Tue, 26 Aug 2003 23:34:58 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 26 Aug 2003 20:22:45 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Tue, 26 Aug 2003 20:22:45 -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; Tue, 26 Aug 2003 20:29:53 -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 19rr0o-0007YX-00 for ; Tue, 26 Aug 2003 20:30:22 -0700 Date: Tue, 26 Aug 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=-3.1 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 #86 - 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-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net) 2. [ rtspspec-Bugs-795314 ] Caching of OPTIONS request (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 26 Aug 2003 05:08:24 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state Bugs item #795295, was opened at 2003-08-26 14:08 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=795295&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: TEARDOWN using * and the Ready-nm state Initial Comment: The 20 february 2002 we discussed http://rtsp.org/bug506412, for conclusion of that discussion see minutes: http://rtsp.org/2002/telecon/minutes20Feb.html However to me it seems that the need for state Ready-nm is not that great. Also the use of "*" as a URL will not work when proxies are present, unless requirements are put on them to maintain certain state in regards to sessions. The use of the presentation URL also is problematic as some sessions may not have a defined session URL, like for example for sessions intended to be used in non-aggregted mode. Therefore my suggestion is that the Ready-nm state is removed and that teardown using "*" is dissallowed. Comments please. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Tue, 26 Aug 2003 05:27:47 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795314 ] Caching of OPTIONS request Bugs item #795314, was opened at 2003-08-26 14:27 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=795314&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Caching of OPTIONS request Initial Comment: Geetha Srikantan thought of the question if OPTIONS request are cachable, and if, how to determine the expiration of such cached command. My answer Maybe, it is actually a problem of what OPTIONS is used for. As long it is only used for determing server capability it is not a problem. However if it is used to maintain session liveness, i.e. session ID present, no. Also depending on the URI and the possibilities to cache ma y vary. Needs further consideration. This is a tough problem. I don't think there are. The Expires header is an entity header, but the text in RFC 2616 seems to mean the whole request. So this is also something that needs consideration. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795314&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 Aug 28 04:35: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 EAA17187 for ; Thu, 28 Aug 2003 04:35: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 19sDFL-0005Tp-6M for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 23:14:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3Ep17021059 for mmusic-archive@odin.ietf.org; Wed, 27 Aug 2003 23:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9qu-0007G1-4T for mmusic-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 19:37: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 TAA19074 for ; Wed, 27 Aug 2003 19:37:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9qs-0003BV-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 19:37:22 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s9qr-0003BS-00 for mmusic-web-archive@ietf.org; Wed, 27 Aug 2003 19:37:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s489-0005lG-1g; Wed, 27 Aug 2003 13:30:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19roDp-00014N-PR for mmusic@optimus.ietf.org; Tue, 26 Aug 2003 20:31: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 UAA26614 for ; Tue, 26 Aug 2003 20:31:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19roDn-000696-00 for mmusic@ietf.org; Tue, 26 Aug 2003 20:31:35 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19roDm-00068c-00 for mmusic@ietf.org; Tue, 26 Aug 2003 20:31:34 -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 h7R0V5lx033033 for ; Tue, 26 Aug 2003 17:31:05 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Aug 2003 17:31:05 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7D7F@misty.packetvideo.com> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Tue, 26 Aug 2003 17:31:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] Interpreting RFC2327: SDP whitespace problem in "s=" line Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org 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: During recent interop testing, one issue has come up regarding whether it is valid to have "s=[single space]" in an SDP as the subject of a presentation. In section 6 of RFC2327 (see http://www.ietf.org/rfc/rfc2327.txt?number=2327): An SDP session description consists of a number of lines of text of the form = is always exactly one character and is case-significant. is a structured text string whose format depends on . It also will be case-significant unless a specific field defines otherwise. Whitespace is not permitted either side of the `=' sign. In general is either a number of fields delimited by a single space character or a free format string. Taken off context, this paragraph seems to be prohibiting '[space]=' or '=[space]' . However, we don't think the intent was to place restrictions on . If is a free-format string, then it should be able to start with a space. (And this is what the ABNF definition says, for the value in the 's=' case). We checked http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt as well, which clearly states that if there is no meaningful subject, a single space should be used in "s=" line, yet it apparently has contracdictory statement in section 5. We hereby would like to confirm with this mailing list, that "s=[single space]" is a legal subject line. We would also appreciate clarification in http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-13.txt , section 5, to indicate that: " An SDP session description consists of a number of lines of text of the form: = where MUST be exactly one case-significant character and is structured text whose format depends on . In general is either a number of fields delimited by a single space character, or a free format string. [modified text] Whitespace MUST NOT be used either side of the "=" sign, except if the free format string begins with a space or contains a single space. An exampel is: "s=[single space]", which is a legal SDP line." Thanks in advance for your feedback. thomas PacketVideo Corp. www.pv.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Aug 29 01:37:10 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 BAA29446 for ; Fri, 29 Aug 2003 01:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sZUo-0004am-SZ for mmusic-archive@odin.ietf.org; Thu, 28 Aug 2003 23:00:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T30IKb017642 for mmusic-archive@odin.ietf.org; Thu, 28 Aug 2003 23:00:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWtO-0004fX-G0 for mmusic-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 20:13: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 UAA02822 for ; Thu, 28 Aug 2003 20:13:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sWtM-00026i-00 for mmusic-web-archive@ietf.org; Thu, 28 Aug 2003 20:13:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sWtL-00026e-00 for mmusic-web-archive@ietf.org; Thu, 28 Aug 2003 20:13:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVRt-0000va-OV; Thu, 28 Aug 2003 18: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 19sSap-0000p0-6n for mmusic@optimus.ietf.org; Thu, 28 Aug 2003 15:38: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 PAA11779 for ; Thu, 28 Aug 2003 15:37:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSan-0005Ex-00 for mmusic@ietf.org; Thu, 28 Aug 2003 15:38:01 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19sSam-0005Es-00 for mmusic@ietf.org; Thu, 28 Aug 2003 15:38:01 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19sSam-00036w-00 for ; Thu, 28 Aug 2003 12:38:00 -0700 Date: Thu, 28 Aug 2003 12:38:00 -0700 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030828193800.GG10789@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sw7tCqrGA+HQ0/zt" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: [MMUSIC] SDP b= clarification Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --Sw7tCqrGA+HQ0/zt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In RFC3556, the example SDP shows multiple b=3Dlines in the media sections.= =20 In RFC2327 (and the updated draft sdp-new-13), the b=3D line is specified without any corresponding note that the line may be repeated. I've always assumed this meant exactly one instance was allowed. If that is the case, the example SDP in 3556 is noncompliant. Since multiple b=3D lines are presumedly desirable, I think the sdp-new draft should be updated to reflect this. --=20 Majority, n.: That quality that distinguishes a crime from a law. --Sw7tCqrGA+HQ0/zt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TloYqznSmcYu2m8RAhaTAJ9msaof+WQUrVU9ZUZS2HYPrMaeNwCfQSP8 UOwoP0CRfeEXXK853XXkV1o= =uptC -----END PGP SIGNATURE----- --Sw7tCqrGA+HQ0/zt-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Aug 29 02:31: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 CAA16907 for ; Fri, 29 Aug 2003 02:31: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 19sZrT-0005pE-7V for mmusic-archive@odin.ietf.org; Thu, 28 Aug 2003 23:23:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T3NhHR022386 for mmusic-archive@odin.ietf.org; Thu, 28 Aug 2003 23:23:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sXKv-0006Mp-V3 for mmusic-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 20:41: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 UAA05366 for ; Thu, 28 Aug 2003 20:41:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sXKt-0002iJ-00 for mmusic-web-archive@ietf.org; Thu, 28 Aug 2003 20:41:55 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sXKs-0002iG-00 for mmusic-web-archive@ietf.org; Thu, 28 Aug 2003 20:41:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sTES-0002w3-KN; Thu, 28 Aug 2003 16:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sRGL-0005tj-Lb for mmusic@optimus.ietf.org; Thu, 28 Aug 2003 14:12: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 OAA06109 for ; Thu, 28 Aug 2003 14:12:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sRGE-0004Lz-00 for mmusic@ietf.org; Thu, 28 Aug 2003 14:12:42 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 19sRGE-0004LS-00 for mmusic@ietf.org; Thu, 28 Aug 2003 14:12:42 -0400 Received: from bisa ([130.209.247.104]:53756 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 19sRFj-0001CN-00; Thu, 28 Aug 2003 19:12:11 +0100 Date: Thu, 28 Aug 2003 19:12:01 +0100 Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-08.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: mmusic@ietf.org To: "Fredrik Lindholm (KI/EAB)" From: Colin Perkins In-Reply-To: <1F55F6582266314A85A55F6241509B6707EF4D8A@Esealnt863.al.sw.ericsson.se> Message-Id: <1F296C06-D983-11D7-988D-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, On Thursday, Aug 14, 2003, at 17:08 Europe/London, Fredrik Lindholm (KI/EAB) wrote: ... >> I have a number of comments on this draft: >> >> - The ABNF in Sections 2.1 and 2.2 is contradictory. The key >> management >> data is defined as "text" in one section, and "quoted-string" in >> the >> other, yet these two types have different ranges of valid >> characters >> (and both are more liberal than the explanatory text, which >> implies >> that only base-64 encoded data is allowed). Similar for the >> protocol >> identifier: the definitions of "non-ws-string" in SDPnew and >> "token" >> in RTSP are not consistent. > > This is as a result from the comments we received before, when we > actually > had consistent strings. At that time the comment was that we should use > what was used in SDP and RTSP respectively (and the recommendations was > to use non-ws-string and token). Please propose what to use. If base-64 encoded text is a requirement, be explicit about that. Whatever is chosen, you will need to give an explicit ABNF definition, and include a comment stating that it is consistent with "non-ws-string" in the SDP section, and consistent with "token" in the RTSP section. >> - The draft repeatedly mentions Kerberos, and indicates that >> Kerberos >> tickets may be included in key management messages, but does not >> specify how this is to be achieved. Should either specify how to >> use >> Kerberos, or remove all references to it. > > It was included as a result of a comment that we should give examples > of more than one protocol that might utilize the framework. It is not > our intention to specify how it can be used. We can agree that there > are > places where we could remove the reference. However, it might be good > at least to keep the most general one in Section 3 to provide an > overview > of the possibilities. Including examples of other protocols which might use the framework in future is appropriate. The problem is that the draft states that Kerberos is supported ("Other protocols MAY use the described attribute and header, e.g. Kerberos"). It should say that the framework is intended to support other key management protocols, for example Kerberos, but that this is subject to future standardisation. Be clear what is a possible future extension, and what is allowed today. >> - The second bullet point on Page 6 mentions that other parameters >> may >> need to be specified for certain key management protocols, but >> does >> not specify how an implementor knows if a particular key >> management >> protocol uses additional parameters. Suggest this is listed as >> part >> of the IANA registration for a particular key management protocol? > > I don't see why IANA should handle this. However, it sounds reasonable > that it should be documented in the key management draft (or a > companion > draft). Each new key management protocol that uses this framework needs to provide this information. The way of ensuring this is to mandate that all new protocols that use the framework are registered with IANA, and that IANA require this information be provided. >> - Section 4 needs to provide strict guidance about the parameters >> and >> specifications needed for new key management protocols. The >> interface >> between the key management protocol and this framework should be >> made >> explicit. > > That is what we have tried to address. Please give examples of what > you think is lacking of that? The draft asks for "the information the key management needs from SDP and RTSP", but doesn't indicate how that information is to be specified. For example, does one extract certain fields from the SDP? Is some information taken from an RTSP method or header? Does this data have to be put into a canonical form? etc. There needs to be almost a "checklist" the protocol designer and IANA can look at, to decide if the new protocol is completely specified. >> - In section 5, how is a beat-down attack prevented when the >> attacker >> wishes to beat-down to no security? What is the correct response >> to >> an answer which suggests no security? > > That would be to terminate/abort the session setup. Okay, but that needs to be specified in the draft. >> The main issue behind these seems to be the desire to define new >> parameters which can be left open for future uses. As was mentioned in >> the context of the "a=gpmd:" attribute, this is not acceptable: there >> needs to be a precise definition of the semantics of any new SDP >> attribute/RTSP header before the draft can advance. > > Ok, but doesn't fixing the above issues make this problem go away? Hopefully. The above issues were specific instances of a general problem with the draft. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic