From mailman-owner@ietf.org Sat Jun 1 06:30:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16755 for ; Sat, 1 Jun 2002 06:30:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA26410 for ; Sat, 1 Jun 2002 06:31:02 -0400 (EDT) Date: Sat, 1 Jun 2002 06:31:02 -0400 (EDT) Message-Id: <200206011031.GAA26410@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: mmusic-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mmusic-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mmusic-web-archive@ietf.org: List Password // URL ---- -------- mmusic@ietf.org ofTV https://www1.ietf.org/mailman/options/mmusic/mmusic-web-archive@ietf.org From mmusic-admin@ietf.org Mon Jun 3 08:40:34 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10169 for ; Mon, 3 Jun 2002 08:40:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07456; Mon, 3 Jun 2002 08:39:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19566 for ; Sat, 1 Jun 2002 16:48:18 -0400 (EDT) Received: from goobox (tog-wakko3.prognet.com [207.188.29.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27372 for ; Sat, 1 Jun 2002 16:47:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sat, 01 Jun 2002 13:48:10 -0700 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Sat, 01 Jun 2002 13:48:09 -0700 (PDT) Received: from usw-sf-list2.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by real.com (8.12.2/8.12.2) with ESMTP id g51KkSMA002828 for ; Sat, 1 Jun 2002 13:46:28 -0700 Received: from usw-sf-list1-b.sourceforge.net ([10.3.1.13] helo=usw-sf-list1.sourceforge.net) by usw-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17EFld-00061j-00 for ; Sat, 01 Jun 2002 13:46:29 -0700 Date: Sat, 01 Jun 2002 13:38:49 -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=0.6 required=5.5 tests=NO_REAL_NAME version=2.20 X-UIDL: 3cf00f4c1b2478e0b0cd1e4dc5570467 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #41 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org 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-563153 ] Appendix C: agg/non-agg mixup (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Fri, 31 May 2002 18:42:37 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup Bugs item #563153, was opened at 2002-05-31 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 Category: General Group: Fix for DS - Typo/Thinko Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Appendix C: agg/non-agg mixup Initial Comment: The initial descriptions of aggregate and non-aggregate contol are reversed, and poorly written. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jun 4 07:56:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24196 for ; Tue, 4 Jun 2002 07:56:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21847; Tue, 4 Jun 2002 07:45:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA21756 for ; Tue, 4 Jun 2002 07:45:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23710; Tue, 4 Jun 2002 07:44:50 -0400 (EDT) Message-Id: <200206041144.HAA23710@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sipping@ietf.org, mmusic@ietf.org, rohc@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 04 Jun 2002 07:44:49 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-sipping-sigcomp-sip-dictionary-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF. Title : The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) static dictionary for Signaling Compression (SigComp) Author(s) : M. Garcia et al. Filename : draft-ietf-sipping-sigcomp-sip-dictionary-02.txt Pages : 29 Date : 03-Jun-02 The Session Initiation Protocol (SIP) [2] is a text-based protocol for initiating and managing communication sessions. The protocol can be compressed by using Signaling Compression (SigComp) [1]. Similarly, the Session Description Protocol (SDP) [24] is a text- based protocol intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This memo defines the SIP/SDP- specific static dictionary that SigComp may use in order to achieve higher efficiency. The dictionary is compression algorithm independent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-sigcomp-sip-dictionary-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sipping-sigcomp-sip-dictionary-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sipping-sigcomp-sip-dictionary-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020603130157.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sipping-sigcomp-sip-dictionary-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sipping-sigcomp-sip-dictionary-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020603130157.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 7 15:46:32 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10534 for ; Fri, 7 Jun 2002 15:46:32 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA09556; Fri, 7 Jun 2002 15:31:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01765 for ; Fri, 7 Jun 2002 15:19:17 -0400 (EDT) Received: from goobox (tog-wakko3.prognet.com [207.188.29.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09590 for ; Fri, 7 Jun 2002 15:18:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 07 Jun 2002 12:19:08 -0700 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Fri, 07 Jun 2002 12:19:08 -0700 (PDT) Received: from usw-sf-list2.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by real.com (8.12.2/8.12.2) with ESMTP id g57JI4MA026125 for ; Fri, 7 Jun 2002 12:18:04 -0700 Received: from usw-sf-list1-b.sourceforge.net ([10.3.1.13] helo=usw-sf-list1.sourceforge.net) by usw-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17GPFM-0005oU-00 for ; Fri, 07 Jun 2002 12:18:04 -0700 Date: Fri, 07 Jun 2002 12:17:15 -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=0.6 required=5.5 tests=NO_REAL_NAME version=2.20 X-UIDL: b2b629462d01b3c3a8d61d255b267113 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #42 - 4 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org 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-563153 ] Appendix C: agg/non-agg mixup (noreply@sourceforge.net) 2. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 (noreply@sourceforge.net) 3. [ rtspspec-Bugs-477402 ] In text references point wrong (noreply@sourceforge.net) 4. [ rtspspec-Bugs-477419 ] Update HTTP references (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 06 Jun 2002 13:24:42 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup Bugs item #563153, was opened at 2002-05-31 18:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Appendix C: agg/non-agg mixup Initial Comment: The initial descriptions of aggregate and non-aggregate contol are reversed, and poorly written. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-06-06 13:24 Message: Logged In: YES user_id=3796 It turns out this had already been fixed in the draft-00 version. However, the wording was still very confusing. This has been fixed in the version checked into CVS. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/sdp.tex.diff?r1=1.3&r2=1.4 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Fri, 07 Jun 2002 07:29:50 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 Bugs item #477404, was opened at 2001-11-02 08:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 Category: None Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in table in chapter 12 Initial Comment: Table with RTSP headers page 45, contains the following errors?: - A session header is not required when using describe. - Proxy Authenticate is missing all values on what it is. - The transport header is specifed as required in 12.0 table, but the text in 12.39 says it MAY be included in requests and responses. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2002-06-07 16:29 Message: Logged In: YES user_id=302620 The table is update using the same structure as the new SIP draft. This is available in CVS. There are still some uncertainties in the table. So please review the table and give comments. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-02-06 14:20 Message: Logged In: YES user_id=302620 The table is also missing the location header. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 23:41 Message: Logged In: YES user_id=437905 RESOLUTION: The latest SIP draft has an equivalent table. It has been recommended that we evaluate this SIP table and unless someone objects and justifies the need to make a change let's adopt the SIP draft specification version. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-23 04:47 Message: Logged In: YES user_id=3796 Here's a discrepency between the initial CVS checkin and RFC 2326 12 Header Field Definitions (Table 3): Change from: Content-Type r req. entity To: Content-Type e req. SET_PARAMETER, ANNOUNCE ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 18:53 Message: Logged In: YES user_id=3796 These are all good examples of what's wrong with this table. We need to do an audit of the table, and we may restructure this table for clarity. Suggestions for a new table format would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Fri, 07 Jun 2002 07:38:50 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477402 ] In text references point wrong Bugs item #477402, was opened at 2001-11-02 08:18 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477402&group_id=23194 Category: None Group: Fix for Draft Standard >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: In text references point wrong Initial Comment: Several in text references are pointing to the wrong references list item. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2002-06-07 16:38 Message: Logged In: YES user_id=302620 This will be automatically fixed by rerunning LATEX and should not be a problem in the future. There is a small possibility that some citations are pointing at the wrong document. A eye should be keept open to check for this type of errors. As these is something that should happend naturally in future profreading this issue can be closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2001-12-14 08:47 Message: Logged In: YES user_id=302620 It is not the actual references themself are wrong but the usage in the descripte text. For example, page 10 HTTP-friendly. Here the PICS item uses reference 15, and 16, but should it not be reference 14 and 15 instead. So my suggestion is to actually check alla [..] to see that they point to the correct reference. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 18:08 Message: Logged In: YES user_id=3796 Magnus, could you clarify which text references are wrong? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477402&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Fri, 07 Jun 2002 08:00:51 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477419 ] Update HTTP references Bugs item #477419, was opened at 2001-11-02 08:41 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477419&group_id=23194 Category: None Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Update HTTP references Initial Comment: HTTP references RFC 2326 reference RFC 2068 which has been obsoleted by RFC 2616. How should you relate to the new RFC, and what to do with removed headers? Following things are missing in RFC2616 - public header ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2002-06-07 17:00 Message: Logged In: YES user_id=302620 All references of type [Hx.y] are updated to point correctly into RFC 2616. Any missing header from RFC 2068 has been copied into the RTSP specification. There still remain possibilities that some change between RFC 2616 and RFC 2068 may effect the protocol. See 19.6.3 in RFC2616 for a list of changes. But so far nothing has been found. The security consideration chapter must be updated. The reference through the nameing of security risk may be broken as the Security chapter is heavily restrucutred in RFC 2616. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-03-21 17:29 Message: Logged In: YES user_id=302620 Also the content-base header is missing ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-14 05:04 Message: Logged In: YES user_id=3796 Ok..now a much better category ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 18:59 Message: Logged In: YES user_id=3796 Agreed. Putting in the "Typo/Thinko" category because, even though it doesn't qualify as either, it's a rote change that someone with the time can just fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477419&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 7 22:08:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20119 for ; Fri, 7 Jun 2002 22:08:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21115; Fri, 7 Jun 2002 21:50:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA21082 for ; Fri, 7 Jun 2002 21:50:50 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19746 for ; Fri, 7 Jun 2002 21:50:18 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g581oHKR019984 for ; Fri, 7 Jun 2002 18:50:17 -0700 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g581oEMB006681 for ; Fri, 7 Jun 2002 18:50:14 -0700 Date: Fri, 7 Jun 2002 18:52:22 -0700 (Pacific Daylight Time) From: Rob Lanphier To: "mmusic@ietf.org" Message-ID: X-X-Sender: robla@goobox.prognet.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP telecon: June 12 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, This is a reminder that another RTSP telecon is coming up on Wednesday, June 12, at 9:00am PDT. There's not an agenda yet, but it's basically going to cover things that have been discussed in email on this list, plus the action items from the last telecon. Details on the telecon can be found here: http://rtsp.org/telecon/ Please send mail to me if you plan on attending. Additionally, we've just submitted a new draft revision of RTSP, which is available here: http://rtsp.org/2002/drafts/draft-ietf-mmusic-rfc2326bis-01.txt http://rtsp.org/2002/drafts/draft-ietf-mmusic-rfc2326bis-01.ps Rob -- Rob Lanphier, Program Manager -- Interoperability, RealNetworks http://realnetworks.com http://rtsp.org http://interop.real.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jun 11 07:12:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18292 for ; Tue, 11 Jun 2002 07:12:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15858; Tue, 11 Jun 2002 07:08:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15829 for ; Tue, 11 Jun 2002 07:07:59 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18058; Tue, 11 Jun 2002 07:07:19 -0400 (EDT) Message-Id: <200206111107.HAA18058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Jun 2002 07:07:19 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-01.txt,.ps Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne et al. Filename : draft-ietf-mmusic-rfc2326bis-01.txt,.ps Pages : 4 Date : 10-Jun-02 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time proper- ties. RTSP provides an extensible framework to enable controlled, on- demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This pro- tocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020610143247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143247.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jun 11 22:07:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19993 for ; Tue, 11 Jun 2002 22:07:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03376; Tue, 11 Jun 2002 22:06:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03345 for ; Tue, 11 Jun 2002 22:06:20 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19952 for ; Tue, 11 Jun 2002 22:05:44 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g5C25kKR003996 for ; Tue, 11 Jun 2002 19:05:46 -0700 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g5C25jMB016368 for ; Tue, 11 Jun 2002 19:05:45 -0700 Date: Tue, 11 Jun 2002 19:08:42 -0700 (Pacific Daylight Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: X-X-Sender: robla@goobox.prognet.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP Telecon Agenda: June 12 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Below is's the agenda for the June 12 teleconference at 9am PDT. Also available here: http://rtsp.org/telecon Rob --- Rob Lanphier, Program Manager -- Interoperability, RealNetworks http://realnetworks.com http://rtsp.org http://interop.real.com ---- RtspTcAgenda12Jun2002 ------------------------------------------------------------------------ 1. Last Telecon Minutes <#section1> 2. Review Action Items/Issues <#section2> 1. "ANNOUNCE before RECORD" <#section2.1> 2. Other UDP implementations <#section2.2> 3. Connection-based/connectionless issue <#section2.3> 4. RTSP Header Table issues <#section2.4> 5. When REDIRECT valid <#section2.5> 3. New Mailing List issues <#section3> 1 Last Telecon Minutes * http://rtsp.org/2002/telecon/minutes15May.html 2 Review Action Items/Issues 2.1 "ANNOUNCE before RECORD" * ACTION ITEM: RL to kick off discussion, AJ to follow up * RL: Ooops * Review of RTSP feature table o Email o ACTION ITEM: AW and RL, publish .xls version + Done o ACTION ITEMS: Divide and conquer: + Section 1: AN + Section 3: AK + Section 4: SS + Section 5: SS + Section 6: AJ + Section 7: RL + The rest...handle later 2.2 Other UDP implementations * ACTION ITEM: SS, ask for other UDP implementations o Done 2.3 Connection-based/connectionless issue * ACTION ITEM: RL: bring up connection-based/connectionless issue o Done 2.4 RTSP Header Table issues * Email * ACTION ITEM: AN, reply to this mail o Done 2.5 When REDIRECT valid * Email * TM: should clarify when session header should come in * ACTION ITEM: TM - send email to MMUSIC in reply to this message o Lots of email discussion on that thread o Magnus' reply 3 New Mailing List issues * RTSP REDIRECT (2) , "Location" header & URI * RTSP REDIRECT (3), continuation after TEARDOWN * Server overriding Transport parameters * Using "Supported" header from SIP _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 04:52:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20690 for ; Wed, 12 Jun 2002 04:52:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11533; Wed, 12 Jun 2002 04:50:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11492 for ; Wed, 12 Jun 2002 04:50:53 -0400 (EDT) Received: from accord-ntsrv3.accord.co.il ([212.199.61.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20635; Wed, 12 Jun 2002 04:50:15 -0400 (EDT) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 11:50:19 +0300 Message-ID: From: "Even, Roni" To: mmusic@ietf.org Cc: avt@ietf.org Date: Wed, 12 Jun 2002 11:50:18 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-media-control-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SDP attributes for Video media Media Control Author(s) : R. Even, O. Levin, P. Koskelainen Filename : draft-even-mmusic-video-media-control-00.txt Pages : 6 Date : 10-Jun-02 This document defines the syntax and the semantics for the new SDP attributes required for handling of video. These attributes are not CODEC specific. A URL for this Internet-Draft is: 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-even-mmusic-video-media-control-00.txt". A list of Internet-Drafts directories can be found in or _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 09:46:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28073 for ; Wed, 12 Jun 2002 09:46:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29417; Wed, 12 Jun 2002 09:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA29331 for ; Wed, 12 Jun 2002 09:44:20 -0400 (EDT) Received: from accord-ntsrv3.accord.co.il ([212.199.61.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27990; Wed, 12 Jun 2002 09:43:41 -0400 (EDT) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 16:43:43 +0300 Message-ID: From: "Even, Roni" To: mmusic@ietf.org Cc: avt@ietf.org Date: Wed, 12 Jun 2002 16:43:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C21217.2ACF1F40" Subject: [MMUSIC] RE: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-0 0.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C21217.2ACF1F40 Content-Type: text/plain; charset="windows-1255" Hi, I have seen that too. This is the text file I submitted Roni > -----Original Message----- > From: Lior Sion [mailto:lior.sion@emblaze.com] > Sent: Wednesday, June 12, 2002 3:41 PM > To: 'Even, Roni' > Subject: RE: [AVT] FWD: I-D > ACTION:draft-even-mmusic-video-media-control-0 0.txt > > > Hi Roni, > > the link you gave brings me some garbage in the draft, can > you please send > me a text file with it? > > thanks, > lior > > -----Original Message----- > From: Even, Roni [mailto:roni.even@polycom.co.il] > Sent: Wednesday, June 12, 2002 11:50 AM > To: mmusic@ietf.org > Cc: avt@ietf.org > Subject: [AVT] FWD: I-D > ACTION:draft-even-mmusic-video-media-control-00.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Title : SDP attributes for Video media Media Control > Author(s) : R. Even, O. Levin, P. Koskelainen > Filename : draft-even-mmusic-video-media-control-00.txt > Pages : 6 > Date : 10-Jun-02 > This document defines the syntax and the semantics for the new SDP > attributes required for handling of video. These attributes > are not CODEC > specific. > > A URL for this Internet-Draft is: > 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-even-mmusic-video-media-control-00.txt". A list of Internet-Drafts directories can be found in or _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt **************************************************************************** ********************** The contents of this email and any attachments are confidential. It is intended for the named recipient(s) only. If you have received this email in error please notify the system manager or the sender immediately and do not disclose the contents to any one or make copies. ** eSafe scanned this email for viruses, vandals and malicious content ** **************************************************************************** ********************** ------_=_NextPart_000_01C21217.2ACF1F40 Content-Type: text/plain; name="draft-even-mmusic-video-media-control-00.txt" Content-Disposition: attachment; filename="draft-even-mmusic-video-media-control-00.txt" Content-Transfer-Encoding: quoted-printable = R. Even=20 Internet Draft = Polycom=20 Document: draft-even-mmusic-video-media- = O. Levin=20 control-00.txt = RADVISION=20 = P. Koskelainen=20 = Columbia University=20 Expires: December 2002 = June 2002=20 =20 =20 SDP attributes for Video media Media = Control=20 =20 =20 Status of this Memo=20 =20 This document is an Internet-Draft and is in full = conformance=20 with all provisions of Section 10 of RFC2026.=20 =20 =20 Internet-Drafts are working documents of the Internet = Engineering=20 Task Force (IETF), its areas, and its working groups. = Note that =20 other groups may also distribute working documents as = Internet- Drafts.=20 =20 Internet-Drafts are draft documents valid for a = maximum of six=20 months and may be updated, replaced, or obsoleted by = other documents=20 at any time. It is inappropriate to use = Internet-Drafts as=20 reference material or to cite them other than as = "work in progress."=20 =20 The list of current Internet-Drafts can be accessed = at=20 http://www.ietf.org/ietf/1id-abstracts.txt=20 The list of Internet-Draft Shadow Directories can be = accessed at=20 http://www.ietf.org/shadow.html.=20 =20 =20 Abstract=20 =20 This document defines the syntax and the semantics = for the new SDP=20 attributes required for handling of video. These = attributes are not=20 CODEC specific. =20 =20 =20 Table of Contents=20 =20 Status of this = Memo................................................1=20 = Abstract...........................................................1=20 1. = Introduction....................................................2=20 2. Conventions used in this = document...............................2=20 3. Video Resolution = Attribute......................................2=20 4. Video Request = Attribute.........................................3=20 5. IANA = Considerations.............................................4=20 6. Security = Considerations.........................................5=20 7. = References......................................................6=20 8. Author's = Addresses..............................................6=20 =20 Even et al. Expires December 2002 = 1=20 =0C =20 =20 1. Introduction=20 =20 Internet multimedia conferencing based on SIP is = picking up with=20 point-to-point and multipoint video conferencing = implementation.=20 Video media has some characteristics that are common = to all video=20 codecs. Video streams can build pictures for = different display=20 resolutions each in a different supported frame rate. = Compressed=20 Video information is typically composed of full = picture frames and=20 frames that reflect changes from previous frames, = this requires some=20 special handling to enable smooth switching of video = source and=20 resynchronization on full pictures. In order to have = better support=20 for video media this draft specifies the SDP syntax = to be used for=20 the described video media properties. These = attributes can be=20 delivered by some signalling protocol (e.g. SIP or = SAP).=20 For example, the defined attributes help to control = video streams=20 belonging to SIP dialogs in a point-to-point call as = well as in a=20 multipoint call. =20 The attributes are especially useful in SIP but may = be used in SAP.=20 =20 2. Conventions used in this document=20 =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", = "SHALL", "SHALL NOT",=20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and = "OPTIONAL" in=20 this document are to be interpreted as described in = RFC-2119 [1].=20 =20 =20 3. Video Resolution Attribute=20 =20 The SDP draft [1] has an attribute of frame rate. = Video CODECs can=20 support different frame rates that are dependent on = the frame=20 resolution. Therefore we need a new attribute that = will specify the=20 frame rate per resolution.=20 =20 a=3Dvideo-resolution:=20 size=3D=94SQCIF=94 =93=3D=94 mpi | =93QCIF=94 = =93=3D=94 mpi | =93CIF=94 =93=3D=94 mpi |=20 =934CIF=94 =93=3D=94 mpi | =9316CIF=94 =93=3D=94 mpi = |=20 =93XMAX=94 =93=3D=94 xmax SP =93YMAX=94 =93=3D=94 = ymax SP =93MPI=94 =93=3D=94 mpi=20 =20 mpi=3D1*3DIGIT=20 xmax=3D1*3DIGIT=20 ymax=3D1*3DIGIT=20 =20 =20 =93video-resolution=94 is a media level attribute = that enables=20 definition of supported resolutions for a video CODEC = for described=20 media.=20 =20 MPI gives the maximum video frame rate in frames/sec. = Decimal=20 representations of fractional values using the = notation=20 "." are allowed. If a resolution = is not specified=20 then the decoder will support the frame rate of the = next highest=20 resolution specified.=20 =20 =20 Even et al. Expires December 2002 = 2=20 =0C =20 =20 =20 SQIF: Sub-QCIF picture size and its MPI value.=20 QCIF: QCIF picture size and its MPI value=20 CIF: CIF picture size and it MPI value=20 4CIF: is 4xCIF picture size and its MPI value=20 16CIF: is 16xCIF picture size and its MPI value.=20 Arbitrary picture size (XMAX, YMAX, MPI): the maximum = X and Y values=20 in pixels for an arbitrary picture size and it MPI = value. The X and=20 Y value must be dividable by 4. =20 =20 =20 4. Video Request Attribute=20 =20 =20 Output of a video CODEC is a frame. The frame can = carry complete (in=20 time) information about a picture or about a picture = segment. These=20 frames are known as =93intra=94 frames. In order to = save bandwidth,=20 other frames can carry only changes relative to = previously sent=20 frames. Frames carrying relative information are = known as =93inter=94=20 frames.=20 =20 Some CODECs (such as H.261 and H.263), in addition to = a =93full=94=20 picture, have a notion of picture slices: MB (Macro = Block) and GOB=20 (Group Of Blocks) or arbitrary slices.=20 =20 The decoder has an ability to recognize = synchronization problem and=20 MUST have an ability to explicitly request from an = encoder for=20 complete (in-time) information of a =93full=94 = picture or of a specific=20 slice of the picture. In addition, when an = application needs to=20 start presenting a new video source, it MUST have the = ability to=20 explicitly request from an encoder for a complete = information about=20 the picture.=20 =20 In case the encoder is aware of the upcoming changes = in the=20 transmitted stream (that would result in = synchronization lost by the=20 decoder), the encoder MUST be able to request the = decoding side to=20 freeze the picture, i.e. to stop presenting the = changes, until a new=20 stable image is encoded and transmitted.=20 =20 =20 A smooth video switch in a multipoint conference = starts when the=20 conference host decides to switch to a new video = source. It sends a=20 freeze picture request to all the decoders that will = receive the new=20 stream. Afterwards, the conferencing host sends a = request to the new=20 encoder to send an Intra frame with the complete = information for the=20 new picture. The new Intra frame, from the encoder, = releases the=20 decoders from the video freeze state and a new = complete picture is=20 presented.=20 =20 =20 The AVT RTCP feedback draft [3] provides a mechanism = for an=20 immediate feedback using RTCP. In order to be in line = with the RTCP=20 role (as described in RTP [4]), the feedback = mechanism is allowed=20 for notifications only. Moreover, the RTCP feedback = provides a=20 =20 Even et al. Expires December 2002 = 3=20 =0C =20 =20 notification channel from decoder to encoder only. = For our purposes,=20 a means of sending requests in both directions are = required.=20 =20 Using SDP (instead of RTCP) has a clear advantage for = applications=20 that don=92t have an access to the RTCP channel of = the media.=20 =20 The media level attributes to support this are:=20 =20 a=3Dvideo-frame:=20 =20 Permitted values for request are:=20 =93INTRA-PICTURE=94 =96 instructing the encoder to = send an intra frame=20 =93FREEZE-PICTURE=94 =96 instructing the decoder to = stop decoding.=20 =93INTRA-GOB=94 =93=3D=94 fgb =93,=94 ngb =96 = instruct the encoder to send ngb gobs=20 starting from gob fgb.=20 =93INTRA-MB=94 =93=3D=94 fgb =93,=94 fmb =93,=94 nmb = =96 instruct the encoder to send=20 nmb macro blocks starting from gob fgb and first = macro block fmb.=20 =20 =20 fmb=3D1*2DIGIT=20 nmb=3D1*2DIGIT=20 fgb=3D1*2DIGIT=20 ngb=3D1*2DIGIT=20 =20 =20 =20 5. IANA Considerations =20 =20 This document defines the following new SDP = parameters of type "att- field" (attribute names): =20 =20 Attribute name: video-resolution=20 Long form name: video resolution . =20 Type of attribute: media-level. =20 Subject to charset: No. =20 Purpose: define supported frame rate = per resolution. =20 Appropriate values: See Section 3. =20 =20 =20 Attribute name: video-frame =20 Long form name: video frame request. =20 Type of attribute: media-level. =20 Subject to charset: No. =20 Purpose: define video frame requests. = Appropriate values: See Section 4. =20 =20 =20 =20 =20 =20 =20 =20 =20 Even et al. Expires December 2002 = 4=20 =0C =20 =20 6. Security Considerations=20 =20 The new SDP attributes do not introduce additional = security=20 pitfalls.=20 The security considerations are the same as for the = SDP [1].=20 =20 Even et al. Expires December 2002 = 5=20 =0C =20 =20 =20 7. References=20 =20 [1] M. Handley and V. Jacobson, "SDP: session = description protocol", =20 Request for Comments 2327, Internet Engineering Task = Force, Apr. 1998.=20 =20 [2] P. Koskelainen et al. =93SDP syntax for H.263 = options=94, =20 INTERNET-DRAFT, Internet Engineering Task Force, 1998.=20 =20 [3] Ott, Wenger et al. =93Extended RTP Profile for = RTCP-based Feedback=20 (RTP/AVPF)=94, INTERNET-DRAFT, Internet Engineering Task = Force, 2002=20 =20 [4] AVT WG, Schulzrinne/Casner/Frederick/Jacobson, = =93RTP: A Transport=20 Protocol for Real-Time Applications=94, RFC 1889, = Proposed Standard, Jan=20 1996.=20 =20 =20 =20 =20 =20 =20 =20 8. Author's Addresses=20 =20 Roni Even=20 Polycom Network Systems=20 94 Derech Em Hamoshavot Phone: = +972-3-9251200=20 Petach Tikva, Israel Email: = roni.even@polycom.co.il=20 =20 Orit Levin=20 RADVISION Inc.=20 575 Corporate Drive=20 Mahwah, NJ 07430 Phone: = +1-210-529-4300 x230=20 USA Email: = orit@radvision.com=20 =20 Petri Koskelainen=20 Dept. of Computer Science=20 Columbia University=20 1214 Amsterdam Avenue Phone:=20 MC 0401 New York Email: = petkos@cs.columbia.edu=20 NY 10027=20 USA=20 =20 =20 =20 Even et al. Expires December 2002 = 6=20 =0C ------_=_NextPart_000_01C21217.2ACF1F40-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 10:04:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28690 for ; Wed, 12 Jun 2002 10:04:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00758; Wed, 12 Jun 2002 10:02:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00649 for ; Wed, 12 Jun 2002 10:02:28 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28623; Wed, 12 Jun 2002 10:01:49 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5CE2MmG003770; Wed, 12 Jun 2002 16:02:22 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA13886; Wed, 12 Jun 2002 16:02:22 +0200 Message-ID: <3D07546E.2080502@era.ericsson.se> Date: Wed, 12 Jun 2002 16:02:22 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Even, Roni" CC: mmusic@ietf.org, IETF AVT WG References: Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [MMUSIC] Re: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-0 0.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Hi, The garbage is a result of using illegal characters (Non ascii) in the draft. The use of smart quotations (“ & ”) should be avoided, use only the standard strait ones ("). Also please remove all the 15 extra left columns before submission the next time. Please read the draft guidelines, "http://www.ietf.org/ietf/1id-guidelines.txt", for other things to consider. Regards Magnus Even, Roni wrote: > Hi, > >I have seen that too. >This is the text file I submitted >Roni > >>-----Original Message----- >>From: Lior Sion [mailto:lior.sion@emblaze.com] >>Sent: Wednesday, June 12, 2002 3:41 PM >>To: 'Even, Roni' >>Subject: RE: [AVT] FWD: I-D >>ACTION:draft-even-mmusic-video-media-control-0 0.txt >> >> >>Hi Roni, >> >>the link you gave brings me some garbage in the draft, can >>you please send >>me a text file with it? >> >>thanks, >>lior >> >>-----Original Message----- >>From: Even, Roni [mailto:roni.even@polycom.co.il] >>Sent: Wednesday, June 12, 2002 11:50 AM >>To: mmusic@ietf.org >>Cc: avt@ietf.org >>Subject: [AVT] FWD: I-D >>ACTION:draft-even-mmusic-video-media-control-00.txt >> >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> Title : SDP attributes for Video media Media Control >> Author(s) : R. Even, O. Levin, P. Koskelainen >> Filename : draft-even-mmusic-video-media-control-00.txt >> Pages : 6 >> Date : 10-Jun-02 >>This document defines the syntax and the semantics for the new SDP >>attributes required for handling of video. These attributes >>are not CODEC >>specific. >> >>A URL for this Internet-Draft is: >>> >edia-control-0 >0.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-even-mmusic-video-media-control-00.txt". > >A list of Internet-Drafts directories can be found in > or > > > > > >_______________________________________________ >Audio/Video Transport Working Group >avt@ietf.org >https://www1.ietf.org/mailman/listinfo/avt >**************************************************************************** >********************** >The contents of this email and any attachments are confidential. >It is intended for the named recipient(s) only. >If you have received this email in error please notify the system manager or >the >sender immediately and do not disclose the contents to any one or make >copies. > >** eSafe scanned this email for viruses, vandals and malicious content ** >**************************************************************************** >********************** > > >------------------------------------------------------------------------ > > > R. Even > Internet Draft Polycom > Document: draft-even-mmusic-video-media- O. Levin > control-00.txt RADVISION > P. Koskelainen > Columbia University > Expires: December 2002 June 2002 > > > SDP attributes for Video media Media Control > > > Status of this Memo > > This document is an Internet-Draft and is in full conformance > with all provisions of Section 10 of RFC2026. > > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six > months and may be updated, replaced, or obsoleted by other documents > at any time. It is inappropriate to use Internet-Drafts as > reference material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > Abstract > > This document defines the syntax and the semantics for the new SDP > attributes required for handling of video. These attributes are not > CODEC specific. > > > Table of Contents > > Status of this Memo................................................1 > Abstract...........................................................1 > 1. Introduction....................................................2 > 2. Conventions used in this document...............................2 > 3. Video Resolution Attribute......................................2 > 4. Video Request Attribute.........................................3 > 5. IANA Considerations.............................................4 > 6. Security Considerations.........................................5 > 7. References......................................................6 > 8. Author's Addresses..............................................6 > > Even et al. Expires December 2002 1 > > > 1. Introduction > > Internet multimedia conferencing based on SIP is picking up with > point-to-point and multipoint video conferencing implementation. > Video media has some characteristics that are common to all video > codecs. Video streams can build pictures for different display > resolutions each in a different supported frame rate. Compressed > Video information is typically composed of full picture frames and > frames that reflect changes from previous frames, this requires some > special handling to enable smooth switching of video source and > resynchronization on full pictures. In order to have better support > for video media this draft specifies the SDP syntax to be used for > the described video media properties. These attributes can be > delivered by some signalling protocol (e.g. SIP or SAP). > For example, the defined attributes help to control video streams > belonging to SIP dialogs in a point-to-point call as well as in a > multipoint call. > The attributes are especially useful in SIP but may be used in SAP. > > 2. Conventions used in this document > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this document are to be interpreted as described in RFC-2119 [1]. > > > 3. Video Resolution Attribute > > The SDP draft [1] has an attribute of frame rate. Video CODECs can > support different frame rates that are dependent on the frame > resolution. Therefore we need a new attribute that will specify the > frame rate per resolution. > > a=video-resolution: > size=”SQCIF” “=” mpi | “QCIF” “=” mpi | “CIF” “=” mpi | > “4CIF” “=” mpi | “16CIF” “=” mpi | > “XMAX” “=” xmax SP “YMAX” “=” ymax SP “MPI” “=” mpi > > mpi=1*3DIGIT > xmax=1*3DIGIT > ymax=1*3DIGIT > > > “video-resolution” is a media level attribute that enables > definition of supported resolutions for a video CODEC for described > media. > > MPI gives the maximum video frame rate in frames/sec. Decimal > representations of fractional values using the notation > "." are allowed. If a resolution is not specified > then the decoder will support the frame rate of the next highest > resolution specified. > > > Even et al. Expires December 2002 2 > > > > SQIF: Sub-QCIF picture size and its MPI value. > QCIF: QCIF picture size and its MPI value > CIF: CIF picture size and it MPI value > 4CIF: is 4xCIF picture size and its MPI value > 16CIF: is 16xCIF picture size and its MPI value. > Arbitrary picture size (XMAX, YMAX, MPI): the maximum X and Y values > in pixels for an arbitrary picture size and it MPI value. The X and > Y value must be dividable by 4. > > > 4. Video Request Attribute > > > Output of a video CODEC is a frame. The frame can carry complete (in > time) information about a picture or about a picture segment. These > frames are known as “intra” frames. In order to save bandwidth, > other frames can carry only changes relative to previously sent > frames. Frames carrying relative information are known as “inter” > frames. > > Some CODECs (such as H.261 and H.263), in addition to a “full” > picture, have a notion of picture slices: MB (Macro Block) and GOB > (Group Of Blocks) or arbitrary slices. > > The decoder has an ability to recognize synchronization problem and > MUST have an ability to explicitly request from an encoder for > complete (in-time) information of a “full” picture or of a specific > slice of the picture. In addition, when an application needs to > start presenting a new video source, it MUST have the ability to > explicitly request from an encoder for a complete information about > the picture. > > In case the encoder is aware of the upcoming changes in the > transmitted stream (that would result in synchronization lost by the > decoder), the encoder MUST be able to request the decoding side to > freeze the picture, i.e. to stop presenting the changes, until a new > stable image is encoded and transmitted. > > > A smooth video switch in a multipoint conference starts when the > conference host decides to switch to a new video source. It sends a > freeze picture request to all the decoders that will receive the new > stream. Afterwards, the conferencing host sends a request to the new > encoder to send an Intra frame with the complete information for the > new picture. The new Intra frame, from the encoder, releases the > decoders from the video freeze state and a new complete picture is > presented. > > > The AVT RTCP feedback draft [3] provides a mechanism for an > immediate feedback using RTCP. In order to be in line with the RTCP > role (as described in RTP [4]), the feedback mechanism is allowed > for notifications only. Moreover, the RTCP feedback provides a > > Even et al. Expires December 2002 3 > > > notification channel from decoder to encoder only. For our purposes, > a means of sending requests in both directions are required. > > Using SDP (instead of RTCP) has a clear advantage for applications > that don’t have an access to the RTCP channel of the media. > > The media level attributes to support this are: > > a=video-frame: > > Permitted values for request are: > “INTRA-PICTURE” – instructing the encoder to send an intra frame > “FREEZE-PICTURE” – instructing the decoder to stop decoding. > “INTRA-GOB” “=” fgb “,” ngb – instruct the encoder to send ngb gobs > starting from gob fgb. > “INTRA-MB” “=” fgb “,” fmb “,” nmb – instruct the encoder to send > nmb macro blocks starting from gob fgb and first macro block fmb. > > > fmb=1*2DIGIT > nmb=1*2DIGIT > fgb=1*2DIGIT > ngb=1*2DIGIT > > > > 5. IANA Considerations > > This document defines the following new SDP parameters of type "att- > field" (attribute names): > > Attribute name: video-resolution > Long form name: video resolution . > Type of attribute: media-level. > Subject to charset: No. > Purpose: define supported frame rate per resolution. > Appropriate values: See Section 3. > > > Attribute name: video-frame > Long form name: video frame request. > Type of attribute: media-level. > Subject to charset: No. > Purpose: define video frame requests. > Appropriate values: See Section 4. > > > > > > > > > > > Even et al. Expires December 2002 4 > > > 6. Security Considerations > > The new SDP attributes do not introduce additional security > pitfalls. > The security considerations are the same as for the SDP [1]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Even et al. Expires December 2002 5 > > > > 7. References > > [1] M. Handley and V. Jacobson, "SDP: session description protocol", > Request for Comments 2327, Internet Engineering Task Force, Apr. 1998. > > [2] P. Koskelainen et al. “SDP syntax for H.263 options”, > INTERNET-DRAFT, Internet Engineering Task Force, 1998. > > [3] Ott, Wenger et al. “Extended RTP Profile for RTCP-based Feedback > (RTP/AVPF)”, INTERNET-DRAFT, Internet Engineering Task Force, 2002 > > [4] AVT WG, Schulzrinne/Casner/Frederick/Jacobson, “RTP: A Transport > Protocol for Real-Time Applications”, RFC 1889, Proposed Standard, Jan > 1996. > > > > > > > > 8. Author's Addresses > > Roni Even > Polycom Network Systems > 94 Derech Em Hamoshavot Phone: +972-3-9251200 > Petach Tikva, Israel Email: roni.even@polycom.co.il > > Orit Levin > RADVISION Inc. > 575 Corporate Drive > Mahwah, NJ 07430 Phone: +1-210-529-4300 x230 > USA Email: orit@radvision.com > > Petri Koskelainen > Dept. of Computer Science > Columbia University > 1214 Amsterdam Avenue Phone: > MC 0401 New York Email: petkos@cs.columbia.edu > NY 10027 > USA > > > > > > > > > > > > > > Even et al. Expires December 2002 6 > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 11:48:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02228 for ; Wed, 12 Jun 2002 11:48:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06406; Wed, 12 Jun 2002 11:43:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06375 for ; Wed, 12 Jun 2002 11:43:19 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01995 for ; Wed, 12 Jun 2002 11:42:45 -0400 (EDT) Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17596; Wed, 12 Jun 2002 08:42:42 -0700 (PDT) Received: from sun.com (vpn-129-149-241-38.SFBay.Sun.COM [129.149.241.38]) by phys-ha2mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA19725; Wed, 12 Jun 2002 08:42:41 -0700 (PDT) Message-ID: <3D076BD2.3030200@sun.com> Date: Wed, 12 Jun 2002 11:42:10 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org CC: rtspspec-logistics@lists.sourceforge.net Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP Feature table, Section 1 review. Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Keys for Column Headings SRV=Server PRY=Proxy CLT=Client Keys for requirements explicitly callout M=MUST MN=MUST NOT SD=SHOULD SDN=SHOULD NOT SL=SHALL SLN=SHALL NOT MAY=MAY NA=NOT APPLICABLE OPT=OPTIONAL REQ=REQUIRED REC=RECOMMENDED Keys for requirements implicitly callout m=must mn=must not sd=should sdn=should not sl=shall sln=shall not may=may na=not applicable opt=optional req=required rec=recommended Other Keys desc=describe para=parameter mthd=method recd=recording conf=conference info=information pres=presentation attr=attribute app=application init=initialization id=identifier req=required diff=different avail=available sync=synchronize auth=authenticate NOTES: 1. Line numbers are exactly as in RFC. Some blank, page header and footer lines have been deleted. 2. Server,Proxy, Client shows explicit and implicit requirements called out. YET TO BE CONFIRMED. 3. Missing requirement callout does not exclude a requirement. LINE FEATURE SUMMARY SECTION SRV PRY CLT 309Rreqs handled by proxies, tunnels caches1.1 Purpose may 324control multiple streams, 1 timeline 1.3 Terminology may may may 330Multiparty, multimedia pres 1.3 Terminology 343client request media data from SRV 1.3 Terminology req req req 347Transport layer virtual circuit 1.3 Terminology info info info 351File contain multiple streams 1.3 Terminology may may may 352comprise a pres 1.3 Terminology may may may 353SRV offer agg. control 1.3 Terminology may may may 354container file not embedded in protocol.1.3 Terminology 357timing sink source relationship 1.3 Terminology info info info 358sink must reproduce source timing 1.3 Terminology m m m 361interactive/realtime continuous media 1.3 Terminology info info info 362streaming/playback cont. media 1.3 Terminology info info info 366info. transferred as payload 1.3 Terminology info info info 367meta info. in entity-header fields 1.3 Terminology req req req 368content in entity-body 1.3 Terminology may may may 372Datatype/codec specific init.. 1.3 Terminology info info info 374Transport independent info. 1.3 Terminology req req req 379media type parameter changed before 1.3 Terminology may may may 380or during stream playback. 1.3 Terminology may may may 383playback or record services for 1.3 Terminology req req req 384one or more media streams 1.3 Terminology req req req 384diff streams within presenatation 1.3 Terminology may may may 385may originate from diff SRVs 1.3 Terminology may may may 399Redirection to diff media SRV. 1.3 Terminology info info info 402media stream is a single media instance 1.3 Terminology info info info 404RTP stream consists of RTP and RTCP 1.3 Terminology req req req 406equivalent to DSM-CC stream([5]). 1.3 Terminology req req req 410structured sequence of octets 1.3 Terminology info info info 411transmit by connection or connectionless1.3 Terminology info info info 415participant may be machine, record, SRV 1.3 Terminology may may may 419one or more streams media feed 1.3 Terminology info info info 420using pres desc. 1.3 Terminology req req req 422agg. control of those streams 1.3 Terminology may may may 425info. about one or more streams 1.3 Terminology info info info 429SDP "session" for live pres. 1.3 Terminology info info info 430pres. desc. takes serveral formats, SDP 1.3 Terminology may may may 434An RTSP response. 1.3 Terminology info info info 435HTTP response indicated explicitly. 1.3 Terminology info info info 438An RTSP request 1.3 Terminology info info info 439HTTP request indicated explicitly. 1.3 Terminology info info info 442complete RTSP "transaction" 1.3 Terminology info info info 457negotiation of transport info. 1.3 Terminology info info info 465New mthds and para. easily added 1.4 Proto. Prop info info info 468can parsed by standard HTTP or MIME 1.4 Proto. Prop info info info 471re-uses web security mechanisms. 1.4 Proto. Prop info info info 472HTTP auth basic (RFC 2068) 1.4 Proto. Prop may may may 473digest auth (RFC 2069) 1.4 Proto. Prop may may may 474reuse transport/network layer security 1.4 Proto. Prop may may may 478use unreliable datagram protocol (UDP) 1.4 Proto. Prop may may may 479reliable datagram protocol RDP, RFC1151 1.4 Proto. Prop may may may 480reliable stream protocol such as TCP 1.4 Proto. Prop may may may 484media stream reside on diff SRV 1.4 Proto. Prop may may may 485CLT establishes control sessions 1.4 Proto. Prop may may may 487Media synch performed at transport 1.4 Proto. Prop m m m 490control both record and playback 1.4 Proto. Prop may may may 491can alternate between two modes 1.4 Proto. Prop may may may 495Stream control divorced conf. 1.4 Proto. Prop 496initiation protocol create unique id. 1.4 Proto. Prop req req req 498SIP [12] or H.323 1.4 Proto. Prop may may may 511frame-level accuracy SMPTE time stamps 1.4 Proto. Prop info info info 512allow remote digital editing. 1.4 Proto. Prop info info info 515does not impose pres or meta 1.4 Proto. Prop 516can convey type of format to be used 1.4 Proto. Prop may may may 518must contain at least one RTSP URI. 1.4 Proto. Prop m m m 521protocol handled by both app. and 1.4 Proto. Prop 522 transport-layer (SOCKS [14]) firewalls 1.4 Proto. Prop sd sd sd 523SETUP mthd open "hole" for UDP 1.4 Proto. Prop may may may 527reuses HTTP concepts 1.4 Proto. Prop info info info 528 existing infrastructure can be reused. 1.4 Proto. Prop info info info 529(Platform for Internet Content Selection1.4 Proto. Prop info info info 531does not just add mthds to HTTP 1.4 Proto. Prop info info info 535startstream,to stopstream 1.4 Proto. Prop m m m 536SRVs not stream CLTs cannot stop 1.4 Proto. Prop sdn sdn sdn 540CLT can negotiate transport mthd 1.4 Proto. Prop may may may 544If basic are disabled, clean mthd for 1.4 Proto. Prop 545CLT to determine mthds not implement 1.4 Proto. Prop m m m 547present appropriate user interface. 1.4 Proto. Prop may may may 551 multi-CLT capability. 1.4 Proto. Prop info info info 553easily extensible to multi-CLT 1.4 Proto. Prop info info info 554stream ids used by svrl ctrl streams 1.4 Proto. Prop may may may 555passing remote would be possible. 1.4 Proto. Prop may may may 556how several CLTs negotiate access; 1.4 Proto. Prop info info info 557left to other "social protocol" 1.4 Proto. Prop info info info 571will support diff sets of requests. 1.5 Extend RTSP info info info 581implement all header fields described 1.5 Extend RTSP SD SD SD 591Existing mthds can be extended 1.5 Extend RTSP may may may 592para. be ignored by recipient. 1.5 Extend RTSP may may may 594if client need negative acknowledgement 1.5 Extend RTSP may may may 595tag to extension be added 1.5 Extend RTSP may may may 596in Require: field 1.5 Extend RTSP may may may 597New mthds can be added. 1.5 Extend RTSP may may may 598not understand responds with 501 1.5 Extend RTSP m m m 599sender should not attempt to use mthd 1.5 Extend RTSP sdn sdn sdn 600CLT use OPTIONS mthd to inquire 1.5 Extend RTSP may may may 601SRV SHOULD list mthds 1.5 Extend RTSP SD SD SD 603new version of protocol can be defined 1.5 Extend RTSP info info info 604allow all aspects to change 1.5 Extend RTSP info info info 609may be identified by an RTSP URL. 1.6 Overall Op. may may may 611defined by pres desc. 1.6 Overall Op. m m m 613desc. obtained by CLT 1.6 Overall Op. may may may 614may not be store on media server 1.6 Overall Op. may may may 624presentation descriptin 1.6 Overall Op. 625describe one or more presentations 1.6 Overall Op. 626each maintains common time axis 1.6 Overall Op. m m m 630 may contain several media streams. 1.6 Overall Op. may may may 632Presentation description contains desc 1.6 Overall Op. m m m 633media stream making up pres, encodings, 1.6 Overall Op. 634language, para. enable CLT to choose 1.6 Overall Op. req req req 635appropriate media combination 1.6 Overall Op. 636each stream is individually controllable1.6 Overall Op. m m m 637identified RTSP URL, points media SRV 1.6 Overall Op. m m m 639streams located on diff SRVs 1.6 Overall Op. may may may 640audio and video streams can split 1.6 Overall Op. may may may 642transport mthds SRV capable of 1.6 Overall Op. may may may 644network destination address and 1.6 Overall Op. info info info 645port need to be determined. 1.6 Overall Op. info info info 649transmitted to source of RTSP request, 1.6 Overall Op. info info info 650port number chosen by CLT. 1.6 Overall Op. info info info 651transmitted same reliable stream RTSP. 1.6 Overall Op. info info info 654picks multicast address and port. 1.6 Overall Op. info info info 660multicast address, port and key 1.6 Overall Op. info info info 661given by conf. desc. 1.6 Overall Op. info info info 666sent via separate protocol, 1.7 RTSP States may may may 669delivery continues no RTSP requests 1.7 RTSP States m m m 678single media stream may be ctrld 1.7 RTSP States may may may 679by RTSP issued sequentially on diff TCP 1.7 RTSP States may may may 680SRV maintain "session state" 1.7 RTSP States m m m 681correlate RTSP requests withstream 1.7 RTSP States m m m 684many mthds not contribute to state 1.7 RTSP States info info info 690Causes SRV to allocate resources 1.7 RTSP States info info info 694Starts transmission allocated via SETUP 1.7 RTSP States info info info 697Temporarily halts stream 1.7 RTSP States info info info 700 Frees resources. Session ceases 1.7 RTSP States info info info 703contribute to state use Session header 1.7 RTSP States info info info 705SRV generates session id.s 1.7 RTSP States info info info 710RTSP overlap with HTTP. 1.8 Other Proto info info info 711interact with HTTP initial contact 1.8 Other Proto may may may 713allow diff hand-off points 1.8 Other Proto info info info 715can be retrieved using HTTP or RTSP 1.8 Other Proto may may may 716reduces roundtrips browser scenarios 1.8 Other Proto info info info 717allow RTSP SRVs with no HTTP 1.8 Other Proto info info info 721out-of-band indiff protocol. 1.8 Other Proto info info info 722asymmetric protocol 1.8 Other Proto info info info 723both CLT and SRV issue request 1.8 Other Proto may may may 724 requests are also not stateless 1.8 Other Proto info info info 725set para. and control stream 1.8 Other Proto may may may 737security and proxies. 1.8 Other Proto info info info 738adopt HTTP caches, proxies and auth 1.8 Other Proto info info info 742RTSPnot tied to RTP. 1.8 Other Proto info info info 744existence pres desc. 1.8 Other Proto info info info 745express static and temporal properties 1.8 Other Proto info info info 746containing several media streams. 1.8 Other Proto info info info _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 12:22:43 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03546 for ; Wed, 12 Jun 2002 12:22:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09504; Wed, 12 Jun 2002 12:18:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09469 for ; Wed, 12 Jun 2002 12:18:34 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03418 for ; Wed, 12 Jun 2002 12:17:54 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CGHsD16067 for ; Wed, 12 Jun 2002 18:17:54 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5CGHqQ15207 for ; Wed, 12 Jun 2002 17:17:53 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Jun 2002 17:17:52 +0100 Message-ID: From: "Mark Watson" To: mmusic@ietf.org Subject: RE: [MMUSIC] media source ip/port in SDP Date: Wed, 12 Jun 2002 17:17:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2122C.AF87095E" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2122C.AF87095E Content-Type: text/plain; charset="iso-8859-1" Does anyone think there is a security risk associated with the fact that the source address/port of the sender is unknown to the receiver ? I understand that there are various ways that the receiver could distinguish RTP packets from the genuine correspondant from those of an attacker, but even so, if the receiver is on a low-bandwidth link, these packets could constitute a DoS attack. A firewall could be used to control admission of packets to the low-bandwidth link based on destination address/port (assuming the client can open an appropriate pinhole), but you would have to wildcard the source address. If the source address of the packets was known, the pinhole could be made more specific, and so prevent attacks from an attacker who knew the destination address/port. Or can we assume that any attacker who knew the destination address/port is probably in a position to spoof the correct source address anyway ? As an aside, should RTCP reports be sent to the address received as source address in incoming RTP packets, or should they be sent to the same address as outgoing RTP packets ? If the latter (and the addresses are different), why is the media sink device of my correspondant interested in RTCP reports for packets generated by the media source device, which has a separate network interface ? Regards, Mark Watson > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: 30 May 2002 21:18 > To: Medhavi Bhatia > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] media source ip/port in SDP > > > From > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offe > r-answer-02.txt: > > The IP address > and port present in the offer indicate nothing about the source IP > address and source port of RTP and RTCP packets that will > be sent by > the offerer. > > -Jonathan R. > > Medhavi Bhatia wrote: > > > > Hi, > > > > I remember there was a discussion some while back about > specifying the > > source ip/port for the media in the SDP. Is that > standardized yet ? I am > > still > > seeing some vendors using the RFC 2327 format, and assuming that the > > source ip or port for media will be the same as the receive > ip or port > > specified in the > > SDP. > > Is that correct or standardized somewhere ? > > > > Medhavi. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > ------_=_NextPart_001_01C2122C.AF87095E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] media source ip/port in SDP

Does anyone think there is a security risk associated = with the fact that the source address/port of the sender is unknown to = the receiver ?

I understand that there are various ways that the = receiver could distinguish RTP packets from the genuine correspondant = from those of an attacker, but even so, if the receiver is on a = low-bandwidth link, these packets could constitute a DoS = attack.

A firewall could be used to control admission of = packets to the low-bandwidth link based on destination address/port = (assuming the client can open an appropriate pinhole), but you would = have to wildcard the source address. If the source address of the = packets was known, the pinhole could be made more specific, and so = prevent attacks from an attacker who knew the destination = address/port.

Or can we assume that any attacker who knew the = destination address/port is probably in a position to spoof the correct = source address anyway ?

As an aside, should RTCP reports be sent to the = address received as source address in incoming RTP packets, or should = they be sent to the same address as outgoing RTP packets ? If the = latter (and the addresses are different), why is the media sink device = of my correspondant interested in RTCP reports for packets generated by = the media source device, which has a separate network interface = ?

Regards,

Mark Watson




> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: 30 May 2002 21:18
> To: Medhavi Bhatia
> Cc: mmusic@ietf.org
> Subject: Re: [MMUSIC] media source ip/port in = SDP
>
>
> From
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-= sdp-offe
> r-answer-02.txt:
>
> The IP address
>    and port present in the offer = indicate nothing about the source IP
>    address and source port of = RTP and RTCP packets that will
> be sent by
>    the offerer.
>
> -Jonathan R.
>
> Medhavi Bhatia wrote:
> >
> > Hi,
> >
> > I remember there was a discussion some = while back about
> specifying the
> > source ip/port for the media in the SDP. = Is that
> standardized yet ? I am
> > still
> > seeing some vendors using the RFC 2327 = format, and assuming that the
> > source ip or port for media will be the = same as the receive
> ip or port
> > specified in the
> > SDP.
> > Is that correct or standardized somewhere = ?
> >
> > Medhavi.
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> = _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

------_=_NextPart_001_01C2122C.AF87095E-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jun 12 23:19:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20815 for ; Wed, 12 Jun 2002 23:19:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12813; Wed, 12 Jun 2002 23:18:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA12784 for ; Wed, 12 Jun 2002 23:18:11 -0400 (EDT) Received: from websmtp03.sohu.com ([61.135.145.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20791 for ; Wed, 12 Jun 2002 23:17:33 -0400 (EDT) From: fyangyu@sohu.com Received: from mail.sohu.com (unknown [192.168.41.140]) by websmtp03.sohu.com (Postfix) with ESMTP id CFF43675C8 for ; Thu, 13 Jun 2002 11:15:40 +0800 (CST) Message-ID: <6380151.1023938282213.JavaMail.postfix@mailsrv11.mail.sohu.com> Date: Thu, 13 Jun 2002 11:18:02 +0800 (CST) To: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Mailer: Sohu Web Mail 2.0.13 X-SHIP: 218.2.137.38 Content-Transfer-Encoding: 8bit Subject: [MMUSIC] Question on draft-ietf-mmusic-sdp-new-10.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Dear fellows: In draft-ietf-mmusic-sdp-new-10.txt page 19, it said "Attribute fields can also be added before the first media field; these "session-level"attributes convey additional information that applies to the conference as a whole rather than to individual media; an example might be the conference's floor control policy." I am interested in describing floor control policy in sdp. But this darft doesn't give a detailed example. Where can i find this example? Thank you! Yu feiyang _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jun 13 03:48:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04070 for ; Thu, 13 Jun 2002 03:48:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01932; Thu, 13 Jun 2002 03:44:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA01901 for ; Thu, 13 Jun 2002 03:44:22 -0400 (EDT) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04013 for ; Thu, 13 Jun 2002 03:43:46 -0400 (EDT) Received: from dynamicsoft.com ([63.113.46.86]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5D7hiYH012772; Thu, 13 Jun 2002 03:43:45 -0400 (EDT) Message-ID: <3D07D173.9060201@dynamicsoft.com> Date: Wed, 12 Jun 2002 18:55:47 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Watson CC: mmusic@ietf.org Subject: Re: [MMUSIC] media source ip/port in SDP References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Mark Watson wrote: > Does anyone think there is a security risk associated with the fact that > the source address/port of the sender is unknown to the receiver ? No. Even if its known, it can be spoofed. If you want secure RTP, I recommend SRTP. > > I understand that there are various ways that the receiver could > distinguish RTP packets from the genuine correspondant from those of an > attacker, but even so, if the receiver is on a low-bandwidth link, these > packets could constitute a DoS attack. SRTP provides an authentication check (I believe) which allows you to distinguish them. > > A firewall could be used to control admission of packets to the > low-bandwidth link based on destination address/port (assuming the > client can open an appropriate pinhole), but you would have to wildcard > the source address. If the source address of the packets was known, the > pinhole could be made more specific, and so prevent attacks from an > attacker who knew the destination address/port. Well, once they find out the source (which would be just as easy as finding out the destination if both were in the SDP), the narrower pinhole doesn't help. > > Or can we assume that any attacker who knew the destination address/port > is probably in a position to spoof the correct source address anyway ? Indeed. > > As an aside, should RTCP reports be sent to the address received as > source address in incoming RTP packets, or should they be sent to the > same address as outgoing RTP packets ? If the latter (and the addresses > are different), Unless signaled explicitly with the sdp4nat extension, RTCP is sent to the same address as RTP, but on a port higher. why is the media sink device of my correspondant > interested in RTCP reports for packets generated by the media source > device, which has a separate network interface ? Why would RTP and RTCP be on different network interfaces?? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jun 13 07:42:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08029 for ; Thu, 13 Jun 2002 07:42:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12985; Thu, 13 Jun 2002 07:42:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA12950 for ; Thu, 13 Jun 2002 07:42:06 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07944 for ; Thu, 13 Jun 2002 07:41:29 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5DBg3mG024615 for ; Thu, 13 Jun 2002 13:42:03 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA14260; Thu, 13 Jun 2002 13:42:03 +0200 Message-ID: <3D08850B.40302@era.ericsson.se> Date: Thu, 13 Jun 2002 13:42:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: <20020516181222.B17452@vernors> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi At yesterdays telecon this issue was again brought up. I will here state what I believe was the conclusions of the discussion. However the issue not settled yet, and more comments are welcome. First I would like to redefine the usage of terms here. I don't believe the use of connectionless and connection-based is really describing what we are discussing. So I will here define some terms that I will use in the discussion below. Connectionless transport: This is a transport layer that does not have a notion of a connection, i.e. no establishment and later teardown on the transport layer. The protocol we have today has these properties are UDP. Connection-based transport: Transport over a protocol that has a connection establishment. The protocol defined to be used with these properties are TCP. As Connection based transport can be used a bit different i would define two use cases for TCP: Persistent TCP: A TCP connection to a RTSP server that is maintained for transport of several request and response messages. Ultimate the connection can kept for all communication between the client and server, even for the setup and teardown of several sessions. Non-Persistent TCP: A TCP connection is only utilized for the exchange of one request/response and then closed. For maximum interoperability towards older clients and greatest flexibility the servers needs to support both persistent and non-persistent TCP. There is no need to define any as default. What should be written in the updated specification is the pro and cons of the two choices. The specification should clarify how the non-persistent is working. This involve the important fact that the network connections needs to be decoupled from the session. A client which closes the TCP connection shall not result in the loss of the session. The session is kept alive until the session times out or is torn down. The time-out expires after a given time, default 60 seconds, without activity. The server should never close a connection unless the session times out, even not after teardown of the session. The session can be kept alive in several ways. Below is a list of things that should reset the session timer: - Any RTSP message with the sessions ID. A list in order of preference of use should be established: Ping, Options with session header. - RTCP messages from the client for the RTP sessions attached to the session's media streams. - The TCP connection if it has keep alive messages verifying that connectivity exist. (I am a little doubting about this. This may not show an application failure correctly) My point is that persistent TCP is actually a special case of non-persistent, and if a server implements non-persistent correctly it will work fine when the client do not close the TCP connection. And then some direct comments to the statements below. Jonathan Sergent wrote: >On Thu, May 16, 2002 at 04:02:22PM -0700, Rob Lanphier wrote: > >>Currently, the RTSP specification says this about the RTSP connection: >> >> There is no notion of an RTSP connection; instead, a server maintains >> a session labeled by an identifier. An RTSP session is in no way tied >> to a transport-level connection such as a TCP connection. During an >> RTSP session, an RTSP client may open and close many reliable >> transport connections to the server to issue RTSP requests. >> Alternatively, it may use a connectionless transport protocol such as >> UDP. >> >>Many operational RTSP clients and servers do treat the underlying TCP >>connection as a significant factor. We've had several conversations to >>date about this, mostly on the RTSP telecon: >> >>http://rtsp.org/2002/telecon/minutes23Jan.html#line90 >>http://rtsp.org/2002/telecon/minutes17Apr.html#section3.9 >> >>...and it's currently listed as issue 477427 on SourceForge: >>http://rtsp.org/bug477427 >> >>Here's the proposed resolution: >> Define header and response for non-persistent connections. >> Default is connection-oriented, and connectionless MAY be implemented. >> Look into SIP "supported" header (defining a feature tag for >> connectionless operation) >> >>In the recent telecons, we've decided that this is an important issue to >>highlight to the group. So, any additional thought on this? >> > >Some thoughts (no claims on these being anything more than thoughts): > >We should be sure to not go down any slippery slopes with respect to >the importance of the Session header on connection-oriented RTSP, so >that servers which currently implement "connectionless" RTSP and do not >attach significance to connections do not suddenly fall out of >compliance. > I agree that we should preserve interoperability and require server to implement non-persistent operations. > >I do agree that it would be nice for the server to get explicit >information as to its expectations for connection lifetime. Right now >the Sun server has various heuristics to keep the connection alive so >that clients which expect connection-oriented behavior are not >disappointed by the loss of the connection while streams are playing. > It would of course be possible to create a feature tag for persistent connections, but are they really needed. With correct separation between connections and the session it does not matter. What is important is the session time-out and keeping it from timing out. With servers supporting non-peristent is does not matter what the clients expect, they simple use what they desire. > >We should also address the issue of multiple sessions on one >connection. I don't know what the right way to do this is. The two >issues are somewhat related. > Yes, some clarifying text on this should be created. My personal view is that it is allowed. All message related to a session will carry the session id, otherwise it is directed to the server in general. Therefore nothing in the protocol that I know of prevents it. > >I also wonder if the default should be connectionless to preserve >compatibility with RFC 2326... we wouldn't want a client which thinks >it can drop the connection safely due to RFC 2326 breaking with a "new >RTSP" server which assumes by default that when the client closes the >TCP connection that it can tear down the playing stream. (But maybe >this isn't an issue if we signal things right; I'm not sure.) > I agree and therefore non-persistent connections need to be supported. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jun 13 08:30:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09328 for ; Thu, 13 Jun 2002 08:30:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15186; Thu, 13 Jun 2002 08:27:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA15152 for ; Thu, 13 Jun 2002 08:27:20 -0400 (EDT) Received: from zctfs063.nortelnetworks.com (zctfs063.nortelnetworks.com [47.164.128.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09111 for ; Thu, 13 Jun 2002 08:26:14 -0400 (EDT) Received: from znsgs01r.europe.nortel.com (znsgs01r.nortelnetworks.com [47.137.129.92]) by zctfs063.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DCQBM27764; Thu, 13 Jun 2002 14:26:12 +0200 (MEST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5DCQAe03513; Thu, 13 Jun 2002 13:26:10 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Jun 2002 13:26:13 +0100 Message-ID: From: "Mark Watson" To: "'Jonathan Rosenberg'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] media source ip/port in SDP Date: Thu, 13 Jun 2002 13:26:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C212D5.7F74C20C" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C212D5.7F74C20C Content-Type: text/plain; charset="iso-8859-1" Jonathan, Thanks for your response - it confirms what I had suspected. Quick follow-up on the RTCP below. > > > > As an aside, should RTCP reports be sent to the address received as > > source address in incoming RTP packets, or should they be > sent to the > > same address as outgoing RTP packets ? If the latter (and > the addresses > > are different), > > Unless signaled explicitly with the sdp4nat extension, RTCP > is sent to > the same address as RTP, but on a port higher. > > why is the media sink device of my correspondant > > interested in RTCP reports for packets generated by the media source > > device, which has a separate network interface ? > > Why would RTP and RTCP be on different network interfaces?? Suppose I am corresponding with someone whose microphone and speakers are separate devices, with their own IP addresses (=> network interfaces). I receive RTP packets from the microphone, and send RTP packets to the speakers. I guess I was thinking of RTCP Receiver Report information, which contains information about the packets I have received from the microphone device. Obviously, the microphone device is most interested in these, but I will send them to the speakers (same place as RTP packets). I suppose I will actually send a Sender Report, continaing count of RTP packets I have sent, so this will be of interest to the speakers as well. So the microphone & speakers will have to communicate between themselves anyway, whichever one got the RTCP. ...Mark ------_=_NextPart_001_01C212D5.7F74C20C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] media source ip/port in SDP

Jonathan,

Thanks for your response - it confirms what I had = suspected.

Quick follow-up on the RTCP below.
 
> >
> > As an aside, should RTCP reports be sent = to the address received as
> > source address in incoming RTP packets, or = should they be
> sent to the
> > same address as outgoing RTP packets ? If = the latter (and
> the addresses
> > are different),
>
> Unless signaled explicitly with the sdp4nat = extension, RTCP
> is sent to
> the same address as RTP, but on a port = higher.
>
>   why is the media sink device of my = correspondant
> > interested in RTCP reports for packets = generated by the media source
> > device, which has a separate network = interface ?
>
> Why would RTP and RTCP be on different network = interfaces??

Suppose I am corresponding with someone whose = microphone and speakers are separate devices, with their own IP = addresses (=3D> network interfaces).

I receive RTP packets from the microphone, and send = RTP packets to the speakers. I guess I was thinking of RTCP Receiver = Report information, which contains information about the packets I have = received from the microphone device. Obviously, the microphone device = is most interested in these, but I will send them to the speakers (same = place as RTP packets).

I suppose I will actually send a Sender Report, = continaing count of RTP packets I have sent, so this will be of = interest to the speakers as well. So the microphone & speakers will = have to communicate between themselves anyway, whichever one got the = RTCP.

...Mark

------_=_NextPart_001_01C212D5.7F74C20C-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jun 13 11:56:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18858 for ; Thu, 13 Jun 2002 11:56:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00991; Thu, 13 Jun 2002 11:51:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00834 for ; Thu, 13 Jun 2002 11:51:51 -0400 (EDT) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18534; Thu, 13 Jun 2002 11:51:16 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl4.philips.com (Postfix) with ESMTP id 865EC45245; Thu, 13 Jun 2002 17:51:50 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA05148; Thu, 13 Jun 2002 17:51:50 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA24858; Thu, 13 Jun 2002 17:51:49 +0200 (MET DST) Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based To: Magnus Westerlund Cc: "mmusic@ietf.org" , mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 13 Jun 2002 17:47:50 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 13/06/2002 17:52:44 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org R2326 says: ******************* 10.8 GET_PARAMETER The GET_PARAMETER request retrieves the value of a parameter of a presentation or stream specified in the URI. The content of the reply and response is left to the implementation. GET_PARAMETER with no entity body may be used to test client or server liveness ("ping"). ******************* I would put more emphase on this mechanism as a systematic way to check for time out/connextion liveness.. typically I would mandate that neither server nor client SHOULD drop a connection (based on a time out) unless they have first tried a GET_PARAMETER to check the other side status. regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com Magnus Westerlund ricsson.se> cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Sent by: Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based mmusic-admin@ietf.org Classification: 13/06/2002 13:42 Hi At yesterdays telecon this issue was again brought up. I will here state what I believe was the conclusions of the discussion. However the issue not settled yet, and more comments are welcome. First I would like to redefine the usage of terms here. I don't believe the use of connectionless and connection-based is really describing what we are discussing. So I will here define some terms that I will use in the discussion below. Connectionless transport: This is a transport layer that does not have a notion of a connection, i.e. no establishment and later teardown on the transport layer. The protocol we have today has these properties are UDP. Connection-based transport: Transport over a protocol that has a connection establishment. The protocol defined to be used with these properties are TCP. As Connection based transport can be used a bit different i would define two use cases for TCP: Persistent TCP: A TCP connection to a RTSP server that is maintained for transport of several request and response messages. Ultimate the connection can kept for all communication between the client and server, even for the setup and teardown of several sessions. Non-Persistent TCP: A TCP connection is only utilized for the exchange of one request/response and then closed. For maximum interoperability towards older clients and greatest flexibility the servers needs to support both persistent and non-persistent TCP. There is no need to define any as default. What should be written in the updated specification is the pro and cons of the two choices. The specification should clarify how the non-persistent is working. This involve the important fact that the network connections needs to be decoupled from the session. A client which closes the TCP connection shall not result in the loss of the session. The session is kept alive until the session times out or is torn down. The time-out expires after a given time, default 60 seconds, without activity. The server should never close a connection unless the session times out, even not after teardown of the session. The session can be kept alive in several ways. Below is a list of things that should reset the session timer: - Any RTSP message with the sessions ID. A list in order of preference of use should be established: Ping, Options with session header. - RTCP messages from the client for the RTP sessions attached to the session's media streams. - The TCP connection if it has keep alive messages verifying that connectivity exist. (I am a little doubting about this. This may not show an application failure correctly) My point is that persistent TCP is actually a special case of non-persistent, and if a server implements non-persistent correctly it will work fine when the client do not close the TCP connection. And then some direct comments to the statements below. Jonathan Sergent wrote: >On Thu, May 16, 2002 at 04:02:22PM -0700, Rob Lanphier wrote: > >>Currently, the RTSP specification says this about the RTSP connection: >> >> There is no notion of an RTSP connection; instead, a server maintains >> a session labeled by an identifier. An RTSP session is in no way tied >> to a transport-level connection such as a TCP connection. During an >> RTSP session, an RTSP client may open and close many reliable >> transport connections to the server to issue RTSP requests. >> Alternatively, it may use a connectionless transport protocol such as >> UDP. >> >>Many operational RTSP clients and servers do treat the underlying TCP >>connection as a significant factor. We've had several conversations to >>date about this, mostly on the RTSP telecon: >> >>http://rtsp.org/2002/telecon/minutes23Jan.html#line90 >>http://rtsp.org/2002/telecon/minutes17Apr.html#section3.9 >> >>...and it's currently listed as issue 477427 on SourceForge: >>http://rtsp.org/bug477427 >> >>Here's the proposed resolution: >> Define header and response for non-persistent connections. >> Default is connection-oriented, and connectionless MAY be implemented. >> Look into SIP "supported" header (defining a feature tag for >> connectionless operation) >> >>In the recent telecons, we've decided that this is an important issue to >>highlight to the group. So, any additional thought on this? >> > >Some thoughts (no claims on these being anything more than thoughts): > >We should be sure to not go down any slippery slopes with respect to >the importance of the Session header on connection-oriented RTSP, so >that servers which currently implement "connectionless" RTSP and do not >attach significance to connections do not suddenly fall out of >compliance. > I agree that we should preserve interoperability and require server to implement non-persistent operations. > >I do agree that it would be nice for the server to get explicit >information as to its expectations for connection lifetime. Right now >the Sun server has various heuristics to keep the connection alive so >that clients which expect connection-oriented behavior are not >disappointed by the loss of the connection while streams are playing. > It would of course be possible to create a feature tag for persistent connections, but are they really needed. With correct separation between connections and the session it does not matter. What is important is the session time-out and keeping it from timing out. With servers supporting non-peristent is does not matter what the clients expect, they simple use what they desire. > >We should also address the issue of multiple sessions on one >connection. I don't know what the right way to do this is. The two >issues are somewhat related. > Yes, some clarifying text on this should be created. My personal view is that it is allowed. All message related to a session will carry the session id, otherwise it is directed to the server in general. Therefore nothing in the protocol that I know of prevents it. > >I also wonder if the default should be connectionless to preserve >compatibility with RFC 2326... we wouldn't want a client which thinks >it can drop the connection safely due to RFC 2326 breaking with a "new >RTSP" server which assumes by default that when the client closes the >TCP connection that it can tear down the playing stream. (But maybe >this isn't an issue if we signal things right; I'm not sure.) > I agree and therefore non-persistent connections need to be supported. Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jun 13 22:35:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09063 for ; Thu, 13 Jun 2002 22:35:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06935; Thu, 13 Jun 2002 22:29:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06906 for ; Thu, 13 Jun 2002 22:29:20 -0400 (EDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08612 for ; Thu, 13 Jun 2002 22:28:44 -0400 (EDT) Received: from mail pickup service by mail8.nc.rr.com with Microsoft SMTPSVC; Thu, 13 Jun 2002 22:27:11 -0400 Received: from ncmx01.mgw.rr.com ([24.93.67.251]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 11 Jun 2002 12:16:06 -0400 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by ncmx01.mgw.rr.com (8.12.2/8.12.2) with ESMTP id g5BEGR3o017542; Tue, 11 Jun 2002 10:16:27 -0400 (EDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA13849 for ietf-123-outbound.05@ietf.org; Tue, 11 Jun 2002 10:05:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA11879 for ; Tue, 11 Jun 2002 07:07:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18058; Tue, 11 Jun 2002 07:07:19 -0400 (EDT) Message-Id: <200206111107.HAA18058@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 11 Jun 2002 07:07:19 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-01.txt,.ps Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne et al. Filename : draft-ietf-mmusic-rfc2326bis-01.txt,.ps Pages : 4 Date : 10-Jun-02 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time proper- ties. RTSP provides an extensible framework to enable controlled, on- demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This pro- tocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020610143247.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020610143247.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 14 02:50:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21566 for ; Fri, 14 Jun 2002 02:50:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23373; Fri, 14 Jun 2002 02:46:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA23342 for ; Fri, 14 Jun 2002 02:46:39 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21526 for ; Fri, 14 Jun 2002 02:46:02 -0400 (EDT) From: hisham.khartabil@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g5E6l5i07043 for ; Fri, 14 Jun 2002 09:47:05 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 14 Jun 2002 09:46:37 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 09:46:37 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 14 Jun 2002 09:46:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 14 Jun 2002 09:46:36 +0300 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7C2031F@esebe019.NOE.Nokia.com> Thread-Topic: whitespace after 's=' in SDP Thread-Index: AcITbzpotRw2po+MTqqs/VF+iN6M+Q== To: X-OriginalArrivalTime: 14 Jun 2002 06:46:36.0948 (UTC) FILETIME=[3ADA5540:01C2136F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id CAA23343 Subject: [MMUSIC] whitespace after 's=' in SDP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Is a whitespace allowed in the s= line of an SDP message? from ABNF grammar: session-name-field = "s=" text CRLF ; generic sub-rules: datatypes text = byte-string byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF The space is %x20 so it can be included in any byte-string. Byte-sting 's= Some Text" should be valid. But the draft also mentions that "Whitespace MUST NOT be used either side of the `=' sign" So, is the grammar wrong? or is s= an exception? Are there any other exceptions? Regards, Hisham _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 14 03:22:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22016 for ; Fri, 14 Jun 2002 03:22:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24861; Fri, 14 Jun 2002 03:18:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA24830 for ; Fri, 14 Jun 2002 03:18:02 -0400 (EDT) Received: from hss.hns.com ([164.164.94.118]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21956 for ; Fri, 14 Jun 2002 03:17:21 -0400 (EDT) From: stoshniwal@hss.hns.com Received: from sampark.hss.hns.com (hssblrmail [192.168.17.10]) by hss.hns.com (8.11.6/8.11.2) with SMTP id g5E7BOH04517; Fri, 14 Jun 2002 12:41:26 +0530 Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256BD8.0027FE37 ; Fri, 14 Jun 2002 12:46:49 +0530 X-Lotus-FromDomain: HSSBLR To: hisham.khartabil@nokia.com cc: mmusic@ietf.org Message-ID: <65256BD8.0027FD55.00@sampark.hss.hns.com> Date: Fri, 14 Jun 2002 12:46:46 +0530 Subject: Re: [MMUSIC] whitespace after 's=' in SDP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi Hisham, Even I had seen this some time ago in one of the drafts. (draft-ietf-mmusic-sdp-offer-answer-02.txt, page 4) What (at least as per the offer-answer draft) is allowed, is : "s=<__a_single_space_followed_by_no_text__> CRLF" Strictly speaking, what is not allowed is: "s= a space and text after the space CRLF" In practice, I believe there are some vendors doing the former (single space) as a part of their s= line within the SDP. Most do not do the latter (space before the text) though. Whether s= is the only line where this is being done? ... again, even I'm curious to know about that. I think it is. Perhaps others can add something here. Hope that helps. Regards, Siddharth. -------------- Siddharth Toshniwal @ Hughes Software Systems Bangalore, India. http://www.hssworld.com hisham.khartabil@nokia.com on 06/14/2002 12:16:36 PM To: mmusic@ietf.org cc: (bcc: Siddharth J Toshniwal/HSSBLR) Subject: [MMUSIC] whitespace after 's=' in SDP Is a whitespace allowed in the s= line of an SDP message? from ABNF grammar: session-name-field = "s=" text CRLF ; generic sub-rules: datatypes text = byte-string byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) ;any byte except NUL, CR or LF The space is %x20 so it can be included in any byte-string. Byte-sting 's= Some Text" should be valid. But the draft also mentions that "Whitespace MUST NOT be used either side of the `=' sign" So, is the grammar wrong? or is s= an exception? Are there any other exceptions? Regards, Hisham _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 14 18:02:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16917 for ; Fri, 14 Jun 2002 18:02:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10040; Fri, 14 Jun 2002 18:01:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA25068 for ; Fri, 14 Jun 2002 13:13:41 -0400 (EDT) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06797 for ; Fri, 14 Jun 2002 13:13:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02118; Fri, 14 Jun 2002 11:13:38 -0600 (MDT) Received: from localhost (vpn-129-149-241-203.SFBay.Sun.COM [129.149.241.203]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16603; Fri, 14 Jun 2002 10:13:37 -0700 (PDT) Date: Fri, 14 Jun 2002 10:10:29 -0700 Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) Cc: "mmusic@ietf.org" To: Magnus Westerlund From: Jonathan Sergent In-Reply-To: <3D08850B.40302@era.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.482) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit On Thursday, June 13, 2002, at 04:42 AM, Magnus Westerlund wrote: > - Any RTSP message with the sessions ID. A list in order of preference > of use should be established: Ping, Options with session header. > - RTCP messages from the client for the RTP sessions attached to the > session's media streams. > - The TCP connection if it has keep alive messages verifying that > connectivity exist. (I am a little doubting about this. This may not > show an application failure correctly) > > My point is that persistent TCP is actually a special case of > non-persistent, and if a server implements non-persistent correctly it > will work fine when the client do not close the TCP connection. This doesn't deal with the server closing the connection. Should the server be able to close the connection after PLAY and assume the client will reconnect if it wants to send a PAUSE? If the client does not expect this, it may stop playing the stream when this happens. --jss. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jun 14 18:40:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18506 for ; Fri, 14 Jun 2002 18:40:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12513; Fri, 14 Jun 2002 18:36:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA12483 for ; Fri, 14 Jun 2002 18:36:39 -0400 (EDT) Received: from purple.nge.isi.edu (wireless221.east.isi.edu [65.123.202.221]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18400 for ; Fri, 14 Jun 2002 18:36:01 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.3/8.12.3) with ESMTP id g5EMaaW3005890; Fri, 14 Jun 2002 18:36:36 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200206142236.g5EMaaW3005890@purple.nge.isi.edu> To: hisham.khartabil@nokia.com cc: mmusic@ietf.org Subject: Re: [MMUSIC] whitespace after 's=' in SDP In-Reply-To: Your message of "Fri, 14 Jun 2002 09:46:36 +0300." <2038BCC78B1AD641891A0D1AE133DBB7C2031F@esebe019.NOE.Nokia.com> Date: Fri, 14 Jun 2002 18:36:36 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> hisham.khartabil@nokia.com writes: >Is a whitespace allowed in the s= line of an SDP message? Yes. >from ABNF grammar: > >session-name-field = "s=" text CRLF > >; generic sub-rules: datatypes >text = byte-string > >byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) > ;any byte except NUL, CR or LF > >The space is %x20 so it can be included in any byte-string. >Byte-sting 's= Some Text" should be valid. > >But the draft also mentions that "Whitespace MUST NOT be used either side of the `=' >sign" Correct. >So, is the grammar wrong? or is s= an exception? Are there any other exceptions? I'd claim that the grammar is correct, in that you still have "=", without spaces, but that in this case the can include whitespace. Just another wart, that can't be fixed without breaking compatibility. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 03:04:26 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23388 for ; Mon, 17 Jun 2002 03:04:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25566; Mon, 17 Jun 2002 03:00:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25519 for ; Mon, 17 Jun 2002 03:00:15 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23288 for ; Mon, 17 Jun 2002 02:59:35 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5H70ArU017366; Mon, 17 Jun 2002 09:00:10 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA07893; Mon, 17 Jun 2002 09:00:10 +0200 Message-ID: <3D0D88FA.8040504@era.ericsson.se> Date: Mon, 17 Jun 2002 09:00:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Sergent CC: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan, I had the following sentence in my previous letter which shows my view on the issue. "The server should never close a connection unless the session times out, even not after teardown of the session." So my answer to your question is NO, the server shall not close the connection. The connection was initiated by the client, so it is the clients to control and decide about. The only two reasons for the server to close a connection is a serious server internal error that can't be recovered from and when the server is taken off line and redirect has been issued in sufficient time before this event. Regards Magnus Jonathan Sergent wrote: > > On Thursday, June 13, 2002, at 04:42 AM, Magnus Westerlund wrote: > >> - Any RTSP message with the sessions ID. A list in order of >> preference of use should be established: Ping, Options with session >> header. >> - RTCP messages from the client for the RTP sessions attached to the >> session's media streams. >> - The TCP connection if it has keep alive messages verifying that >> connectivity exist. (I am a little doubting about this. This may not >> show an application failure correctly) >> >> My point is that persistent TCP is actually a special case of >> non-persistent, and if a server implements non-persistent correctly >> it will work fine when the client do not close the TCP connection. > > > This doesn't deal with the server closing the connection. Should the > server be able to close the connection after PLAY and assume the > client will reconnect if it wants to send a PAUSE? If the client does > not expect this, it may stop playing the stream when this happens. > > --jss. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 03:13:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23488 for ; Mon, 17 Jun 2002 03:13:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26481; Mon, 17 Jun 2002 03:11:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26451 for ; Mon, 17 Jun 2002 03:11:42 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23442 for ; Mon, 17 Jun 2002 03:11:02 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5H7BdrU021795; Mon, 17 Jun 2002 09:11:39 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA08289; Mon, 17 Jun 2002 09:11:38 +0200 Message-ID: <3D0D8BAA.50204@era.ericsson.se> Date: Mon, 17 Jun 2002 09:11:38 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: philippe.gentric@philips.com CC: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Philippe, Of course the GET_PARAMETER is one possibility which should be on the list. But I do believe it will be on the same level of recommendation as OPTIONS. The disadvantage with GET_PARAMETER is that it is not in the minimal implementation set. GET_PARAMETER also has a semantic implication of fetching values of parameters. Of course without body it does not result in that serious amount of work for the server. Still it can carry headers that will result in message expansion. Therefore I recommend the usage of PING. On advantage of GET_PARAMETER is the possibility to create a parameter that contains the time since last timer update. In that way the client can check to see that RTCP works as intended with keeping the session alive. Regards Magnus philippe.gentric@philips.com wrote: >R2326 says: > >******************* > >10.8 GET_PARAMETER > > The GET_PARAMETER request retrieves the value of a parameter of a > presentation or stream specified in the URI. The content of the reply > and response is left to the implementation. GET_PARAMETER with no > entity body may be used to test client or server liveness ("ping"). > >******************* > >I would put more emphase on this mechanism >as a systematic way to check for time out/connextion liveness.. > >typically I would mandate that neither server nor client SHOULD >drop a connection (based on a time out) unless they have first tried >a GET_PARAMETER to check the other side status. > > >regards, > > >Philippe Gentric >Software Architect >Philips MP4Net >philippe.gentric@philips.com >http://www.mpeg-4.philips.com > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 09:01:05 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29891 for ; Mon, 17 Jun 2002 09:01:05 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11971; Mon, 17 Jun 2002 08:56:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA11917 for ; Mon, 17 Jun 2002 08:56:50 -0400 (EDT) Received: from gw-nl4.philips.com (gw-nl4.philips.com [212.153.190.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29689; Mon, 17 Jun 2002 08:56:11 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl4.philips.com (Postfix) with ESMTP id 843E444CDA; Mon, 17 Jun 2002 14:56:44 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA03922; Mon, 17 Jun 2002 14:56:44 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA28021; Mon, 17 Jun 2002 14:56:43 +0200 (MET DST) Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based To: Magnus Westerlund Cc: "mmusic@ietf.org" , mmusic-admin@ietf.org, Jonathan Sergent X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 17 Jun 2002 14:52:42 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 17/06/2002 14:57:37 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org but a server *has* to garbage collect inactive sessions, otherwise it would be a sitting duck for DOSA ! Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com Magnus Westerlund ricsson.se> cc: "mmusic@ietf.org" Sent by: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) mmusic-admin@ietf.org Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based Classification: 17/06/2002 09:00 Hi Jonathan, I had the following sentence in my previous letter which shows my view on the issue. "The server should never close a connection unless the session times out, even not after teardown of the session." So my answer to your question is NO, the server shall not close the connection. The connection was initiated by the client, so it is the clients to control and decide about. The only two reasons for the server to close a connection is a serious server internal error that can't be recovered from and when the server is taken off line and redirect has been issued in sufficient time before this event. Regards Magnus Jonathan Sergent wrote: > > On Thursday, June 13, 2002, at 04:42 AM, Magnus Westerlund wrote: > >> - Any RTSP message with the sessions ID. A list in order of >> preference of use should be established: Ping, Options with session >> header. >> - RTCP messages from the client for the RTP sessions attached to the >> session's media streams. >> - The TCP connection if it has keep alive messages verifying that >> connectivity exist. (I am a little doubting about this. This may not >> show an application failure correctly) >> >> My point is that persistent TCP is actually a special case of >> non-persistent, and if a server implements non-persistent correctly >> it will work fine when the client do not close the TCP connection. > > > This doesn't deal with the server closing the connection. Should the > server be able to close the connection after PLAY and assume the > client will reconnect if it wants to send a PAUSE? If the client does > not expect this, it may stop playing the stream when this happens. > > --jss. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 09:03:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00014 for ; Mon, 17 Jun 2002 09:03:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12244; Mon, 17 Jun 2002 09:00:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12205 for ; Mon, 17 Jun 2002 09:00:09 -0400 (EDT) Received: from gw-nl3.philips.com (gw-nl3.philips.com [212.153.190.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29834 for ; Mon, 17 Jun 2002 08:59:26 -0400 (EDT) From: philippe.gentric@philips.com Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl3.philips.com (Postfix) with ESMTP id 1C0793B54C; Mon, 17 Jun 2002 15:00:03 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA10374; Mon, 17 Jun 2002 15:00:02 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA01488; Mon, 17 Jun 2002 15:00:01 +0200 (MET DST) Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based To: Magnus Westerlund Cc: "mmusic@ietf.org" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 17 Jun 2002 14:55:57 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 17/06/2002 15:00:56 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org ping tells you if the machine is up but it does not check if the server is launched/ready Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.mpeg-4.philips.com Magnus Westerlund cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based 17/06/2002 09:11 Classification: Hi Philippe, Of course the GET_PARAMETER is one possibility which should be on the list. But I do believe it will be on the same level of recommendation as OPTIONS. The disadvantage with GET_PARAMETER is that it is not in the minimal implementation set. GET_PARAMETER also has a semantic implication of fetching values of parameters. Of course without body it does not result in that serious amount of work for the server. Still it can carry headers that will result in message expansion. Therefore I recommend the usage of PING. On advantage of GET_PARAMETER is the possibility to create a parameter that contains the time since last timer update. In that way the client can check to see that RTCP works as intended with keeping the session alive. Regards Magnus philippe.gentric@philips.com wrote: >R2326 says: > >******************* > >10.8 GET_PARAMETER > > The GET_PARAMETER request retrieves the value of a parameter of a > presentation or stream specified in the URI. The content of the reply > and response is left to the implementation. GET_PARAMETER with no > entity body may be used to test client or server liveness ("ping"). > >******************* > >I would put more emphase on this mechanism >as a systematic way to check for time out/connextion liveness.. > >typically I would mandate that neither server nor client SHOULD >drop a connection (based on a time out) unless they have first tried >a GET_PARAMETER to check the other side status. > > >regards, > > >Philippe Gentric >Software Architect >Philips MP4Net >philippe.gentric@philips.com >http://www.mpeg-4.philips.com > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 10:14:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04332 for ; Mon, 17 Jun 2002 10:14:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17249; Mon, 17 Jun 2002 10:11:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA17212 for ; Mon, 17 Jun 2002 10:11:00 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04118 for ; Mon, 17 Jun 2002 10:10:22 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5HEAxrU020503; Mon, 17 Jun 2002 16:10:59 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA19802; Mon, 17 Jun 2002 16:10:58 +0200 Message-ID: <3D0DEDF2.8090604@era.ericsson.se> Date: Mon, 17 Jun 2002 16:10:58 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Philippe, I agree with you that a session must remove inactive sessions. However as long as the client shows life signs at least once every timeout interval (normally 60 seconds) the session is alive. And as long as the client shows signs of life the server has no reason for closing the connection. I will further clarify what I guess you misunderstood about teardown. The server should not close a TCP connection as a response to the RTSP teardown request for that session. The client might want to set up a new session without spending unnecessary RTT on TCP connections. If the client is through communicating with the server it should send a TCP close. Was there something else I was unclear about? Regards Magnus philippe.gentric@philips.com wrote: > >but a server *has* to garbage collect inactive sessions, otherwise it would be a sitting duck for DOSA ! > > > >Hi Jonathan, > >I had the following sentence in my previous letter which shows my view >on the issue. > >"The server should never close a connection unless the session times >out, even not after teardown of the session." > >So my answer to your question is NO, the server shall not close the >connection. The connection was initiated by the client, so it is the >clients to control and decide about. The only two reasons for the server >to close a connection is a serious server internal error that can't be >recovered from and when the server is taken off line and redirect has >been issued in sufficient time before this event. > >Regards > >Magnus > >Jonathan Sergent wrote: > Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jun 17 11:40:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08104 for ; Mon, 17 Jun 2002 11:40:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22649; Mon, 17 Jun 2002 11:36:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA22614 for ; Mon, 17 Jun 2002 11:36:11 -0400 (EDT) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07911 for ; Mon, 17 Jun 2002 11:35:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11681; Mon, 17 Jun 2002 09:36:05 -0600 (MDT) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.82.111]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02765; Mon, 17 Jun 2002 08:36:05 -0700 (PDT) Received: from vernors.eng.sun.com (localhost [127.0.0.1]) by vernors.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5HFa52s029269; Mon, 17 Jun 2002 08:36:05 -0700 (PDT) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5HFa44N029268; Mon, 17 Jun 2002 08:36:04 -0700 (PDT) Date: Mon, 17 Jun 2002 08:36:04 -0700 From: Jonathan Sergent To: Magnus Westerlund Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based Message-ID: <20020617083604.D29124@vernors> References: <3D0D88FA.8040504@era.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0D88FA.8040504@era.ericsson.se>; from magnus.westerlund@era.ericsson.se on Mon, Jun 17, 2002 at 09:00:10AM +0200 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org On Mon, Jun 17, 2002 at 09:00:10AM +0200, Magnus Westerlund wrote: > "The server should never close a connection unless the session times > out, even not after teardown of the session." This means that the server has to know which sessions are bound to which connections, which is what I was trying to avoid, since it is potentially troublesome to implement. What if you reference a single session on multiple connections? Which connection does the session keep open? All of them? The most recently used one? It is not obvious what the client will expect. If the answer is "all of them", this seems like an easy opportunity for clients to cause the server to keep lots of connections open, since it only needs to send traffic with the session ID on one connection to keep all of them open. -- Jonathan Sergent / sergent@sun.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jun 18 02:47:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08755 for ; Tue, 18 Jun 2002 02:47:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20980; Tue, 18 Jun 2002 02:43:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA20947 for ; Tue, 18 Jun 2002 02:43:06 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08709 for ; Tue, 18 Jun 2002 02:42:28 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5I6h3Rb022566; Tue, 18 Jun 2002 08:43:04 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id IAA12688; Tue, 18 Jun 2002 08:43:03 +0200 Message-ID: <3D0ED677.1060601@era.ericsson.se> Date: Tue, 18 Jun 2002 08:43:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Sergent CC: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan, Yes, I made a mistake and did not thought of the implications having a session time-out effect the connections. I agree with you that the transport connections and sessions should be decoupled. A RTSP message to a session should only be forward to the session based on the session id header. This decoupling would result in that two different time-outs must exist. One for the RTSP session which functions as discussed earlier. The other takes care of the transport connections. So how do we solve the time-out of the transport connections? The goal as I see it, is that the server should not close any connections unless the client has stopped using them and forgotten to close them. If this can be used it will avoid the potential backwards compatibility issues. The implications such a scheme will have on security is a valid question. What are the possibilities for an attacker to use up all available connections to a server by opening connections and keeping them alive with regular messages? Will this port exhaustion attack be less a problem with larger possibilities for a server to close connections? My TCP knowledge is not that good, what type of keep-alive exist within TCP. Can this be used to reliably determine when the client has forgotten to close a connection to the server and is not any longer responding? Also what time-out does this keep-alive have if it exist? Hope that we can solve this problem Magnus Jonathan Sergent wrote: >On Mon, Jun 17, 2002 at 09:00:10AM +0200, Magnus Westerlund wrote: > >>"The server should never close a connection unless the session times >>out, even not after teardown of the session." >> > >This means that the server has to know which sessions are bound to >which connections, which is what I was trying to avoid, since it is >potentially troublesome to implement. What if you reference a single >session on multiple connections? Which connection does the session >keep open? All of them? The most recently used one? It is not >obvious what the client will expect. > >If the answer is "all of them", this seems like an easy opportunity for >clients to cause the server to keep lots of connections open, since it >only needs to send traffic with the session ID on one connection to >keep all of them open. > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jun 18 03:17:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09099 for ; Tue, 18 Jun 2002 03:17:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22381; Tue, 18 Jun 2002 03:15:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA22350 for ; Tue, 18 Jun 2002 03:15:42 -0400 (EDT) Received: from hclnpd.hclt.co.in ([202.54.64.7]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09040 for ; Tue, 18 Jun 2002 03:14:57 -0400 (EDT) Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MR12V2AY; Tue, 18 Jun 2002 12:44:18 +0530 Received: from npd.hcltech.com (venaraya-pc.hclt-ntl.co.in [192.168.19.60]) by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g5I771L32423; Tue, 18 Jun 2002 12:37:02 +0530 Message-ID: <3D0EEBCC.6B14CEE6@npd.hcltech.com> Date: Tue, 18 Jun 2002 13:44:04 +0530 From: Venkat N Reply-To: venaraya@npd.hcltech.com Organization: HCl Technologies X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: philippe.gentric@philips.com, IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based References: <3D0DEDF2.8090604@era.ericsson.se> Content-Type: multipart/alternative; boundary="------------A3838F22D82333D575A0DA70" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --------------A3838F22D82333D575A0DA70 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Magnus, Few points which I have in mind: The server should have the right to close the connection in case of timeout and this right need not always be with the client . Assuming the client does not close the connection and is not actually sending any request , then in this case the server would be polling on this filedescriptor also among the set of connected filedescriptors which could be avoided . When the client sends a TearDown , we understand that the session is no longer valid and all resources have been released . The above implies that the connection is still valid and a subsequent request by the client could take place in the same connection instead of going for a "SETUP" in a different connection .But here we also need to consider how long can we have the connection alive . -- Regards, -Venkat Visit http://cdn.hcltech.com/ Magnus Westerlund wrote: > Hi Philippe, > > I agree with you that a session must remove inactive sessions. However > as long as the client shows life signs at least once every timeout > interval (normally 60 seconds) the session is alive. And as long as the > client shows signs of life the server has no reason for closing the > connection. > > I will further clarify what I guess you misunderstood about teardown. > The server should not close a TCP connection as a response to the RTSP > teardown request for that session. The client might want to set up a new > session without spending unnecessary RTT on TCP connections. If the > client is through communicating with the server it should send a TCP close. > > Was there something else I was unclear about? > > Regards > > Magnus > > philippe.gentric@philips.com wrote: > > > > >but a server *has* to garbage collect inactive sessions, otherwise it would be a sitting duck for DOSA ! > > > > > > > >Hi Jonathan, > > > >I had the following sentence in my previous letter which shows my view > >on the issue. > > > >"The server should never close a connection unless the session times > >out, even not after teardown of the session." > > > >So my answer to your question is NO, the server shall not close the > >connection. The connection was initiated by the client, so it is the > >clients to control and decide about. The only two reasons for the server > >to close a connection is a serious server internal error that can't be > >recovered from and when the server is taken off line and redirect has > >been issued in sufficient time before this event. > > > >Regards > > > >Magnus > > > >Jonathan Sergent wrote: > > > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic --------------A3838F22D82333D575A0DA70 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Magnus,
  
Few points which I have in mind:



The server should have the right to close the



connection in case of timeout and this right



need not always be with the client .



Assuming the client does not close the connection



and is not actually sending any request , then



in this case the server would be polling on this



filedescriptor also among the set of connected filedescriptors



which could be avoided .






When the client sends a TearDown , we understand that



the session is no longer valid and all resources have been



released  .



The above implies that the connection is still valid and



a subsequent request by the client could take place in



the same connection instead of going for a "SETUP" in



a different connection .But here we also need to



consider how long can we have the connection alive .









-- 
 Regards,
-Venkat

Visit http://cdn.hcltech.com/

 

 

 

 

Magnus Westerlund wrote:

Hi Philippe,

I agree with you that a session must remove inactive sessions. However

as long as the client shows life signs at least once every timeout

interval (normally 60 seconds) the session is alive. And as long as
the

client shows signs of life the server has no reason for closing the

connection.

I will further clarify what I guess you misunderstood about teardown.

The server should not close a TCP connection as a response to the RTSP

teardown request for that session. The client might want to set up
a new

session without spending unnecessary RTT on TCP connections. If the

client is through communicating with the server it should send a TCP
close.

Was there something else I was unclear about?

Regards

Magnus

philippe.gentric@philips.com wrote:

>

>but a server *has* to garbage collect inactive sessions, otherwise
it would be a sitting duck for DOSA !

>

>

>

>Hi Jonathan,

>

>I had the following sentence in my previous letter which shows my
view

>on the issue.

>

>"The server should never close a connection unless the session times

>out, even not after teardown of the session."

>

>So my answer to your question is NO, the server shall not close the

>connection. The connection was initiated by the client, so it is the

>clients to control and decide about. The only two reasons for the
server

>to close a connection is a serious server internal error that can't
be

>recovered from and when the server is taken off line and redirect
has

>been issued in sufficient time before this event.

>

>Regards

>

>Magnus

>

>Jonathan Sergent wrote:

>

 

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A

----------------------------------------------------------------------

Ericsson Radio Systems AB  | Phone +46 8 4048287

Torshamsgatan 23          
| Fax   +46 8 7575550

S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se

_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www1.ietf.org/mailman/listinfo/mmusic




 

--------------A3838F22D82333D575A0DA70--


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Tue Jun 18 03:46:46 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09519
	for ; Tue, 18 Jun 2002 03:46:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23836;
	Tue, 18 Jun 2002 03:44:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA23805
	for ; Tue, 18 Jun 2002 03:44:42 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09466
	for ; Tue, 18 Jun 2002 03:44:04 -0400 (EDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5I7iYrU019540;
	Tue, 18 Jun 2002 09:44:34 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id JAA14290; Tue, 18 Jun 2002 09:44:34 +0200
Message-ID: <3D0EE4E1.7010602@era.ericsson.se>
Date: Tue, 18 Jun 2002 09:44:33 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: venaraya@npd.hcltech.com
CC: IETF MMUSIC WG 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0DEDF2.8090604@era.ericsson.se> <3D0EEBCC.6B14CEE6@npd.hcltech.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Venkat,

I agree with your points. As a clarification and in reference to to my 
latest message to jonathan, there is need for time-out on both the RTSP 
session and the transport connection. If any of the time-out happens, 
the resources related to time-out can be released. What we haven't 
resolved so far is what the value of the transport time-out is and how 
it should work.

Regards

Magnus 

Venkat N wrote:

> Hi Magnus,
>  
> Few points which I have in mind:
> The server should have the right to close the
> connection in case of timeout and this right
> need not always be with the client .
> Assuming the client does not close the connection
> and is not actually sending any request , then
> in this case the server would be polling on this
> filedescriptor also among the set of connected filedescriptors
> which could be avoided .
> When the client sends a TearDown , we understand that
> the session is no longer valid and all resources have been
> released  .
> The above implies that the connection is still valid and
> a subsequent request by the client could take place in
> the same connection instead of going for a "SETUP" in
> a different connection .But here we also need to
> consider how long can we have the connection alive .
>
>-- 
> Regards,
>-Venkat
>
>Visit http://cdn.hcltech.com/
>
>  
>
>  
>   
>

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Tue Jun 18 06:17:57 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11399
	for ; Tue, 18 Jun 2002 06:17:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01922;
	Tue, 18 Jun 2002 06:14:09 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01891
	for ; Tue, 18 Jun 2002 06:14:07 -0400 (EDT)
Received: from hclnpd.hclt.co.in ([202.54.64.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11348
	for ; Tue, 18 Jun 2002 06:13:25 -0400 (EDT)
Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id MR12VJ56; Tue, 18 Jun 2002 15:42:51 +0530
Received: from npd.hcltech.com (creddy-pc.hclt-ntl.co.in [192.168.19.67])
	by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g5I9AqL04562;
	Tue, 18 Jun 2002 14:41:32 +0530
Message-ID: <3D0EFAA3.E218E560@npd.hcltech.com>
Date: Tue, 18 Jun 2002 14:47:23 +0530
From: Narsimha Reddy CH 
Reply-To: creddy@npd.hcltech.com
Organization: HCL Technologies Ltd.
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Westerlund 
CC: IETF MMUSIC WG 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0DEDF2.8090604@era.ericsson.se> <3D0EEBCC.6B14CEE6@npd.hcltech.com> <3D0EE4E1.7010602@era.ericsson.se>
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Magnus,

  The following  are the  points that I have in mind regarding TCP
   transmission timeout ,

  If the server is simply waiting for data from the client, there is
  no way  to tell if the peer has silently gone away, or just isn't
  ready to send any more data yet.  Due to this the server
  may run out of resources after some time.

  The solution could be to use the KEEPALIVEs.  The transport
  layer periodically probes the connection to ensure that the
  connection is alive.  As far as I know the default timeout is 2 hours
  on most unix flavours.  It can be set to a different value in most
  UNIX systems through a kernel parameter and will then affect
  all the TCP connections with the option set.

  But this doesn't make any sense for shortlived connections ( in
  case of  other protocols ) to keep the connection open  even if
  there is no data flowing.

   Regards,
- Narsimha Reddy CH


Magnus Westerlund wrote:

> Hi Venkat,
>
> I agree with your points. As a clarification and in reference to to my
> latest message to jonathan, there is need for time-out on both the RTSP
> session and the transport connection. If any of the time-out happens,
> the resources related to time-out can be released. What we haven't
> resolved so far is what the value of the transport time-out is and how
> it should work.
>
> Regards
>
> Magnus
>
> Venkat N wrote:
>
> > Hi Magnus,
> >
> > Few points which I have in mind:
> > The server should have the right to close the
> > connection in case of timeout and this right
> > need not always be with the client .
> > Assuming the client does not close the connection
> > and is not actually sending any request , then
> > in this case the server would be polling on this
> > filedescriptor also among the set of connected filedescriptors
> > which could be avoided .
> > When the client sends a TearDown , we understand that
> > the session is no longer valid and all resources have been
> > released  .
> > The above implies that the connection is still valid and
> > a subsequent request by the client could take place in
> > the same connection instead of going for a "SETUP" in
> > a different connection .But here we also need to
> > consider how long can we have the connection alive .
> >
> >--
> > Regards,
> >-Venkat
> >
> >Visit http://cdn.hcltech.com/
> >
> >
> >
> >
> >
> >
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research ERA/TVA/A
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Tue Jun 18 09:43:03 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16941
	for ; Tue, 18 Jun 2002 09:43:02 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12968;
	Tue, 18 Jun 2002 09:41:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23726
	for ; Mon, 17 Jun 2002 11:57:24 -0400 (EDT)
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08622;
	Mon, 17 Jun 2002 11:56:44 -0400 (EDT)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
	by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g5HFv5p29962;
	Mon, 17 Jun 2002 11:57:05 -0400 (EDT)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA06574; Mon, 17 Jun 2002 17:57:03 +0200 (MET DST)
To: , , ,
        , , ,
        , , ,
        , , 
Received: from ouranos by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id RAA06555; Mon, 17 Jun 2002 17:56:49 +0200 (MET DST)
Message-ID: <01de01c21617$a602b790$9981cdd4@ouranos>
Reply-To: "Nikos A. Nikolaou" 
From: "Nikos A. Nikolaou" 
Original-To: , , ,
        , , ,
        , , ,
        , , 
Date: Mon, 17 Jun 2002 18:57:04 +0300
Organization: Lucent Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] CFP: Special Issue in IEEE Network on Network Management
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

My apologies if you receive multiple copies of this.

A pdf version of this CFP will be available soon at
http://www.comsoc.org/pubs/net/ntwrk/special.html

Kind regards,
Nikos A. Nikolaou


-------------------------------------------------------------------------------
                        Call For Papers
                IEEE Network Magazine Special Issue on
    Network Management of Multi-service, Multimedia, IP-based Networks

Guest Editors

Dr. Nikolaos Nikolaou                   Dr. Theodore Zahariadis
Lucent Technologies                     Networking & Multimedia Systems
Bell Labs - AT, EMEA                    Ellemedia Technologies
Botterstraat 45                         Syggrou 223,
1270 AA, Huizen,                        171 21, Athens
The Netherlands                         Greece
Tel: +31 - 35 - 687 5302                Tel: +30 - 10 - 937 3097
Email: nikolaou@lucent.com              Email: zahariad@ellemedia.com

Prof. Joan Serrat                       Dr. Bharat Doshi
Telecommunication Engineering           Lucent Technologies
Universitat Politecnica de Catalunya    Bell Labs
Sor Eulalia d'Anzizu, s/n,              101 Crawfords Corner Rd,
08034, Barcelona,                       Holmdel, NJ  07733
Spain                                   USA
Tel: +34 - 93 - 401 6786                Tel: +1732 949 0823
Email: serrat@tsc.upc.es                Email: bdoshi@lucent.com


Objectives

During the last decade, innovations concerning optical networking technology, as
well as advances in digital compression and transmission over copper and cable
have dramatically increased the capabilities and the efficiency of existing and
imminent access-, metropolitan- and core-networks. A major breakthrough in
communications was the fast deployment of cellular systems. Currently, 3G
wireless systems, targeting the transmission of voice, video and high-speed
data, are already under preliminary deployment. Furthermore, researchers and
vendors are expressing a growing interest in 4G wireless systems that will
support even higher rates and cater for global roaming across multiple wireless
networks.

Meanwhile, based on the TCP/IP protocol suite, the Internet has evolved from a
research network, targeting a limited audience of academic and military users,
to a huge and commercially operated network. Next-generation IP technology has
the potential to prevail, both in the access and in the core, as we are moving
toward a worldwide, multi-service, multimedia and high-speed networking
environment. The explosion of IP-based multimedia applications led to an
exponential growth of IP traffic and initiated a number of research activities
that would allow efficient Quality of Service (QoS) support. Additionally, the
issue of security became more important and acquired considerable attention
owing to the proliferation of IP-based Virtual Private Networks (VPNs).

However, apart from efficient compression, sophisticated transmission schemes
and support for QoS, mobility and security, contemporary networking applications
require significant functionality for management operations, ensuring that the
underlining network is both available and capable of supporting the service
uninterruptedly. Configuration, performance and fault management over
heterogeneous underlying technologies and multi-layered networks, along with
end-to-end QoS, traffic management, service control platforms, billing and
mobility management are also crucial components of multi-service and high-speed
IP-based networks.

The goal of this special issue in IEEE Network Magazine is to present to the
magazine's audience (1) a comprehensive study of the design, performance and
deployment issues and solutions of end-to-end network management over
multi-domain, multi-technology, IP-based networks, and (2) a consolidated
insight into ongoing research, development and trials' evaluation of network
management technologies and platforms, broadening future research directions. To
achieve this goal, this special issue seeks for original papers with strong
tutorial and/or survey perspective that will consolidate and present the
leading-edge research prototype development, trials and early deployment and
performance studies in Network Management of multi-service, multimedia, IP-based
networks.


Topics

In particular, focused tutorial and survey contributions are solicited on (but
not restricted to) the following areas:
* End-to-end IP multimedia network and service management
* VoIP, IP Video, streaming, interactive video service management
* Provisioning of multimedia networks and services
* Wireless LAN and 3G/4G mobile multimedia network management
* Management of terminal and network mobility
* Inter-domain IP over WDM multimedia network management
* Network management models and architectures
* Management issues for billing and security for IP multimedia services
* Multi-domain, multi-point, multicast services management
* Policy-based management for multimedia services
* Performance and Fault Management of Multi-layered Networks
* QoS management
* Multimedia traffic management
* Active multimedia network management
* Middleware support for management


Manuscript Submission

Interested authors should submit an electronic version of the manuscript, in
either Postscript or PDF format, as an email attachment to one of the guest
editors.

Additional information including "Guidelines for authors" is available at the
IEEE Network Website: http://www.comsoc.org/pubs/net/ntwrk/authors.html


Important Dates

Submission Deadline:            October 1, 2002
Notification of Acceptance:     December 21, 2002
Final Manuscript Due:           March 1, 2003
Publication Date:               May/June 2003
-------------------------------------------------------------------------------



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Tue Jun 18 10:13:02 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18578
	for ; Tue, 18 Jun 2002 10:13:01 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14574;
	Tue, 18 Jun 2002 10:05:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14487
	for ; Tue, 18 Jun 2002 10:05:25 -0400 (EDT)
Received: from hclnpd.hclt.co.in ([202.54.64.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18066
	for ; Tue, 18 Jun 2002 10:03:57 -0400 (EDT)
Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id MR12VLL9; Tue, 18 Jun 2002 17:45:13 +0530
Received: from npd.hcltech.com (venaraya-pc.hclt-ntl.co.in [192.168.19.60])
	by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g5IC7uL11434;
	Tue, 18 Jun 2002 17:37:56 +0530
Message-ID: <3D0F2466.DCC7D8DF@npd.hcltech.com>
Date: Tue, 18 Jun 2002 17:45:34 +0530
From: Venkat N 
Reply-To: venaraya@npd.hcltech.com
Organization: HCl Technologies
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Magnus Westerlund 
CC: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> <3D0ED677.1060601@era.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------BCF902FA2680A6BEEE3C3E98"
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org


--------------BCF902FA2680A6BEEE3C3E98
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Magnus ,

There are two things we could consider here :

1.
I presume that most  application protocols like ftp  implement
timeouts  in such a way that a crossing of a particular time-period
would imply  closing the connection (i.e if nothing comes from the client
then it is as good as connection closed ).

2. If the  connnection has to be maintained  for a long time period then
   there arises a possibility of using SO_KEEPALIVE .
   On linux  systems this is present in the file
proc/sys/net/ipv4/tcp_keepalive_time
   and defaults to  7200 secs .
  This seems too big a value  and would affect all TCP connections with the
   option set.


Another possibility could be a mechanism running btn client
and server for maintaining the connections.The drawback
with this approach is that it may not be applicable to
all clients as the protocol or mechanism is only between
a particular client and server .

It looks to me that keeping the connection open for sending
a subsequent "SETUP" request is definitely an advantage
but we also need to consider the polling done by the server
on all the connected filedescriptors. If there are 100 connections
to a server and 90 of them are idle for a long time then this
would amount to clogging the system resources.

So deciding on the timeout is still a question and my  view is that the
connection
need not remain open if there is no transmission of data .


--
 Regards,
-Venkat

Visit http://cdn.hcltech.com/








Magnus Westerlund wrote:

> Hi Jonathan,
>
> Yes, I made a mistake and did not thought of the implications having a
> session time-out effect the connections. I agree with you that the
> transport connections and sessions should be decoupled. A RTSP message
> to a session should only be forward to the session based on the session
> id header.
>
> This decoupling would result in that two different time-outs must exist.
> One for the RTSP session which functions as discussed earlier. The other
> takes care of the transport connections.
>
> So how do we solve the time-out of the transport connections? The goal
> as I see it, is that the server should not close any connections unless
> the client has stopped using them and forgotten to close them. If this
> can be used it will avoid the potential backwards compatibility issues.
> The implications such a scheme will have on security is a valid
> question. What are the possibilities for an attacker to use up all
> available connections to a server by opening connections and keeping
> them alive with regular messages? Will this port exhaustion attack be
> less a problem with larger possibilities for a server to close connections?
>
>  My TCP knowledge is not that good, what type of keep-alive exist within
> TCP. Can this be used to reliably determine when the client has
> forgotten to close a connection to the server and is not any longer
> responding? Also what time-out does this keep-alive have if it exist?
>
> Hope that we can solve this problem
>
> Magnus
>
> Jonathan Sergent wrote:
>
> >On Mon, Jun 17, 2002 at 09:00:10AM +0200, Magnus Westerlund wrote:
> >
> >>"The server should never close a connection unless the session times
> >>out, even not after teardown of the session."
> >>
> >
> >This means that the server has to know which sessions are bound to
> >which connections, which is what I was trying to avoid, since it is
> >potentially troublesome to implement.  What if you reference a single
> >session on multiple connections?  Which connection does the session
> >keep open?  All of them?  The most recently used one?  It is not
> >obvious what the client will expect.
> >
> >If the answer is "all of them", this seems like an easy opportunity for
> >clients to cause the server to keep lots of connections open, since it
> >only needs to send traffic with the session ID on one connection to
> >keep all of them open.
> >
> >
>
> --
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research ERA/TVA/A
> ----------------------------------------------------------------------
> Ericsson Radio Systems AB  | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic



--------------BCF902FA2680A6BEEE3C3E98
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi Magnus ,

There are two things we could consider here :

1.

I presume that most  application protocols like ftp  implement

timeouts  in such a way that a crossing of a particular time-period

would imply  closing the connection (i.e if nothing comes from
the client

then it is as good as connection closed ).

2. If the  connnection has to be maintained  for a long time
period then

   there arises a possibility of using SO_KEEPALIVE .

   On linux  systems this is present in the file proc/sys/net/ipv4/tcp_keepalive_time

   and defaults to  7200 secs .

  This seems too big a value  and would affect all TCP connections
with the

   option set.

 

Another possibility could be a mechanism running btn client

and server for maintaining the connections.The drawback

with this approach is that it may not be applicable to

all clients as the protocol or mechanism is only between

a particular client and server .

It looks to me that keeping the connection open for sending

a subsequent "SETUP" request is definitely an advantage

but we also need to consider the polling done by the server

on all the connected filedescriptors. If there are 100 connections

to a server and 90 of them are idle for a long time then this

would amount to clogging the system resources.

So deciding on the timeout is still a question and my  view is
that the connection

need not remain open if there is no transmission of data .

 

-- 
 Regards,
-Venkat

Visit http://cdn.hcltech.com/

 

 

 

 

 

Magnus Westerlund wrote:

Hi Jonathan,

Yes, I made a mistake and did not thought of the implications having
a

session time-out effect the connections. I agree with you that the

transport connections and sessions should be decoupled. A RTSP message

to a session should only be forward to the session based on the session

id header.

This decoupling would result in that two different time-outs must exist.

One for the RTSP session which functions as discussed earlier. The
other

takes care of the transport connections.

So how do we solve the time-out of the transport connections? The goal

as I see it, is that the server should not close any connections unless

the client has stopped using them and forgotten to close them. If this

can be used it will avoid the potential backwards compatibility issues.

The implications such a scheme will have on security is a valid

question. What are the possibilities for an attacker to use up all

available connections to a server by opening connections and keeping

them alive with regular messages? Will this port exhaustion attack
be

less a problem with larger possibilities for a server to close connections?

 My TCP knowledge is not that good, what type of keep-alive exist
within

TCP. Can this be used to reliably determine when the client has

forgotten to close a connection to the server and is not any longer

responding? Also what time-out does this keep-alive have if it exist?

Hope that we can solve this problem

Magnus

Jonathan Sergent wrote:

>On Mon, Jun 17, 2002 at 09:00:10AM +0200, Magnus Westerlund wrote:

>

>>"The server should never close a connection unless the session times

>>out, even not after teardown of the session."

>>

>

>This means that the server has to know which sessions are bound to

>which connections, which is what I was trying to avoid, since it is

>potentially troublesome to implement.  What if you reference
a single

>session on multiple connections?  Which connection does the session

>keep open?  All of them?  The most recently used one? 
It is not

>obvious what the client will expect.

>

>If the answer is "all of them", this seems like an easy opportunity
for

>clients to cause the server to keep lots of connections open, since
it

>only needs to send traffic with the session ID on one connection to

>keep all of them open.

>

>

--

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A

----------------------------------------------------------------------

Ericsson Radio Systems AB  | Phone +46 8 4048287

Torshamsgatan 23          
| Fax   +46 8 7575550

S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se

_______________________________________________

mmusic mailing list

mmusic@ietf.org

https://www1.ietf.org/mailman/listinfo/mmusic



 

--------------BCF902FA2680A6BEEE3C3E98--


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Tue Jun 18 12:05:49 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24532
	for ; Tue, 18 Jun 2002 12:05:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26351;
	Tue, 18 Jun 2002 12:03:13 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26302
	for ; Tue, 18 Jun 2002 12:03:10 -0400 (EDT)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24340
	for ; Tue, 18 Jun 2002 12:02:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14660;
	Tue, 18 Jun 2002 09:02:40 -0700 (PDT)
Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.82.111])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21299;
	Tue, 18 Jun 2002 09:02:39 -0700 (PDT)
Received: from vernors.eng.sun.com (localhost [127.0.0.1])
	by vernors.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g5IG2c2s011660;
	Tue, 18 Jun 2002 09:02:38 -0700 (PDT)
Received: (from jsergent@localhost)
	by vernors.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g5IG2cld011659;
	Tue, 18 Jun 2002 09:02:38 -0700 (PDT)
Date: Tue, 18 Jun 2002 09:02:38 -0700
From: Jonathan Sergent 
To: Magnus Westerlund 
Cc: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
Message-ID: <20020618090238.D11102@vernors.eng.sun.com>
References:  <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> <3D0ED677.1060601@era.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3D0ED677.1060601@era.ericsson.se>; from magnus.westerlund@era.ericsson.se on Tue, Jun 18, 2002 at 08:43:03AM +0200
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

On Tue, Jun 18, 2002 at 08:43:03AM +0200, Magnus Westerlund wrote:
> Yes, I made a mistake and did not thought of the implications having a 
> session time-out effect the connections. I agree with you that the 
> transport connections and sessions should be decoupled. A RTSP message 
> to a session should only be forward to the session based on the session 
> id header.
> 
> This decoupling would result in that two different time-outs must exist. 
> One for the RTSP session which functions as discussed earlier. The other 
> takes care of the transport connections.
> 
> So how do we solve the time-out of the transport connections? The goal 
> as I see it, is that the server should not close any connections unless 
> the client has stopped using them and forgotten to close them. If this 
> can be used it will avoid the potential backwards compatibility issues. 
> The implications such a scheme will have on security is a valid 
> question. What are the possibilities for an attacker to use up all 
> available connections to a server by opening connections and keeping 
> them alive with regular messages? Will this port exhaustion attack be 
> less a problem with larger possibilities for a server to close connections?

Incoming connections will not use up server-side port numbers, since
they will all be bound to port 554 (or whatever port the RTSP server is
listening on) on the server side.

There is still obviously a resource exhaustion issue if you mandate
that the server never close the connection.  

I do not know what the right behavior should be.  My gut feeling is
that the client SHOULD attempt to reconnect to the server if it wants
to send an RTSP command and it discovers that its connection has been
lost.

It's probably worthwhile to allow either the client or the server to
request a "persistent connection" on a session with a feature tag that
tells the other end to not shut down.  This feature tag, in addition to
what has been proposed before, could also enforce a 1:1
session-connection binding for the session and connection in question.
If the client sent it to the server, it would tell the server to make
the session and connection timeouts the same, and to always shut down
the session if the connection goes away.  It would also tell the client
not to shut down the connection during the middle of the session.  The
server should be able to ask this of the client independently of
whether the client has asked it of the server.  The server might want
to request this if a clustering system was in use where the client
might be reconnected to a different server.  So it should be able to
tell the client "if you hang up the connection, I am going to terminate
your session.

This way we only have tightly-coupled session-connection binding, or
no coupling at all, rather than a continuum of options.

The easiest thing for most typical media player clients will be to
always request the option.

But one can imagine applications where this is not desirable; for
example, a client might send PLAY with the clock field set in the Range
header to schedule a playout at some time in the future.  This could be
used for a scheduled broadcast.  It would be undesirable to require
that the TCP connection remain open until the broadcast actually
starts, which might be several hours.  So it is worthwhile to allow
clients to not request the 1:1 session-connection mapping.


P.S.  The server may also decide to drop client sessions and
connections as a load shedding activity.  It would be helpful if this
had well-defined meaning for the client so that the server can do this
while still complying to the protocol.  The client could be required to
expect that the server may want to refuse service to it after a stream
has started playing.  I am not sure how useful it is to specify
something like this.

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 19 08:22:18 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15498
	for ; Wed, 19 Jun 2002 08:22:18 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23238;
	Wed, 19 Jun 2002 08:20:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA23198
	for ; Wed, 19 Jun 2002 08:20:52 -0400 (EDT)
Received: from accord-ntsrv3.accord.co.il ([212.199.61.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15403;
	Wed, 19 Jun 2002 08:20:10 -0400 (EDT)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Jun 2002 15:20:17 +0300
Message-ID: 
From: "Even, Roni" 
To: "'mmusic@ietf.org'" 
Cc: "'avt@ietf.org'" 
Date: Wed, 19 Jun 2002 15:19:26 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-media-control-00.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Hi,
Due to some typing error this is a fixed version




A New Internet-Draft is available from the on-line Internet-Drafts
directories. 
	Title : SDP attributes for Video media Media Control 
	Author(s) : R. Even, O. Levin, P. Koskelainen 
	Filename : draft-even-mmusic-video-media-control-00.txt 
	Pages : 6 
	Date : 10-Jun-02 
This document defines the syntax and the semantics for the new SDP
attributes required for handling of video. These attributes are not CODEC
specific. 

A URL for this Internet-Draft is:
 
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-even-mmusic-video-media-control-00.txt". 

A list of Internet-Drafts directories can be found in
 or
 




_______________________________________________
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 mmusic-admin@ietf.org  Wed Jun 19 09:32:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17973
	for ; Wed, 19 Jun 2002 09:32:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26512;
	Wed, 19 Jun 2002 09:30:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26468
	for ; Wed, 19 Jun 2002 09:30:12 -0400 (EDT)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17798
	for ; Wed, 19 Jun 2002 09:29:31 -0400 (EDT)
Received: from alchesay (alchesay-9.mcs.anl.gov [140.221.9.36])
	by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id IAA133078
	for ; Wed, 19 Jun 2002 08:29:34 -0500
Reply-To: 
From: "Ivan R. Judson" 
To: 
Date: Wed, 19 Jun 2002 08:29:30 -0500
Organization: Argonne National Laboratory
Message-ID: <000901c21795$575c7c00$2409dd8c@alchesay>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] RTSP Test/Validation Tool?
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit


Hello,

I'm wondering if there's any tool to do RTSP validation (both
correctness and spec comprehensiveness)?

--Ivan

..........
Ivan R. Judson .~. http://www.mcs.anl.gov/~judson
Futures Laboratory .~.  630 252 0920
Argonne National Laboratory .~. 630 252 6424 Fax
 


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 19 09:33:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18039
	for ; Wed, 19 Jun 2002 09:33:52 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27105;
	Wed, 19 Jun 2002 09:33:04 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26313
	for ; Wed, 19 Jun 2002 09:29:48 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17775;
	Wed, 19 Jun 2002 09:29:05 -0400 (EDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g5JDScQ09780;
	Wed, 19 Jun 2002 15:28:39 +0200 (MEST)
Message-ID: <3D108765.D6D6F3@tzi.uni-bremen.de>
Date: Wed, 19 Jun 2002 15:30:13 +0200
From: Joerg Ott 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Even, Roni" 
CC: "'mmusic@ietf.org'" , "'avt@ietf.org'" 
Subject: Re: [MMUSIC] FWD: I-D 
 ACTION:draft-even-mmusic-video-media-control-00.txt
References: 
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Roni,

a couple of quick comments on the draft:

Section 3 looks ok to me.  I like the idea of minimizing the number
of parameters one has to deal with.  The BNF needs some fixing to
allow for fractional value but that's straightforward.

In addition, you need to specify the handling of this attribute
for the offer/answer and for the session annoucement case.
E.g. for offer/answer multiple video-resolution attributes may
be included since the two parties intend to negotiate a proper
mode of operation.  For SAP announcements, however, the semantics
are different.

I have concerns regarding section four though.  You are describing
two different aspects there:

1. notifying the receiver(s) about an upcoming change in the media
   stream ("freeze picture")

2. allowing the receiver(s) to instruct the sender to use a certain
   repair mechanism.

You propose both to be implemented by means of SDP in the signaling
path.  While I consent that the information carried are valuable
and possibly required in certain scenarios, I am not sure that
SDP carried in the signaling path is the right answer to your
needs.

Item 1) could be looked at in two different ways: a picture freeze
can be thought of something of longer duration which happens rather
infrequently such as a mute operation (using a=inactive carried via
SIP) for hold/unhold operations but I do not think that the area of
application is really comparable.  In my opinion, what you want to
do, is provide some kind of marker (possibly included in the media
stream) that indicates that decoding shall stop until a certain
condition (e.g. the intra frame from another source) is received.
This seems highly video-specific and better be reasonably synchronized
with the media stream.  SDP is definitely not an ideal option (what
would you do if you not have a separate signaling path as in
broadcasting applications).  RTCP is better but the information may
not reach the receivers in a timely fashion; information contained
within the media stream itself (or the RTP headers) migth be a
better alternative (but I suspect that some religion may be
involved here).

Item 2) is clearly related to the feedback work we have been doing.
The primary issue seems to be that we prefer to provide "hints"
to the other side while you prefer to call those hints "commands"
and require the other side to act accordingly.  Again, I do not
see SDP being a suitable candidate to carry this information;
any such feedback via SDP is likely to take longer to reach the
sender compared to using RTCP -- and if you have multiple commands
to send, you are bound to one command per SIP transaction.

For item 2), I'd like to point out that SDP is also the wrong
place from a semantics perspective.  Indicating a certain temporary
receiver condition is fundamentally different from indicating a
(change in a) media stream property; those two aspects should not
be confused and hence different mechanisms should be applied here.

I'll be happy to try and find an RTP/RTCP-based solution but
SDP is a bad idea for this.

Joerg


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 19 10:15:51 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19906
	for ; Wed, 19 Jun 2002 10:15:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29438;
	Wed, 19 Jun 2002 10:11:57 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29381
	for ; Wed, 19 Jun 2002 10:11:53 -0400 (EDT)
Received: from accord-ntsrv3.accord.co.il ([212.199.61.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19648;
	Wed, 19 Jun 2002 10:11:13 -0400 (EDT)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id ; Wed, 19 Jun 2002 17:11:19 +0300
Message-ID: 
From: "Even, Roni" 
To: "'Joerg Ott'" ,
        "Even, Roni"
	 
Cc: "'mmusic@ietf.org'" , "'avt@ietf.org'" 
Subject: RE: [MMUSIC] FWD: I-D  ACTION:draft-even-mmusic-video-media-contr
	ol-00.txt
Date: Wed, 19 Jun 2002 17:09:55 +0300
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Hi Joerg,
Thanks for your comments.

1. About the BNF I will fix it.

2. I thought of having a section describing the usage in SIP and SAP but
noticed that other drafts like offer/answer and simple capabilities do not
have section about SIP usage. If you meant that you want to explain how the
encoder uses this attribute to select the mode of operation I can add this

3. About fast update and freeze. 
	3.1 Using RTCP feedback for update was discussed in the last meeting
and I agreed with the AVT guys that this should not be there
	3.2 I would like to look at the new picture and freeze picture in
the same context as a new codec request. This means that we use signalling
to ask for a new codec and I see this feature as the same since I am asking
for the same codec but with a new picture. If you want to look at it from
the decoder wants a new codec or a new picture. Since changing a codec
during a session is working in SAP and in SIP I do not see the problem

Thanks
Roni Even

> -----Original Message-----
> From: Joerg Ott [mailto:jo@tzi.uni-bremen.de]
> Sent: Wednesday, June 19, 2002 4:30 PM
> To: Even, Roni
> Cc: 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D 
> ACTION:draft-even-mmusic-video-media-control-00.txt
> 
> 
> Roni,
> 
> a couple of quick comments on the draft:
> 
> Section 3 looks ok to me.  I like the idea of minimizing the number
> of parameters one has to deal with.  The BNF needs some fixing to
> allow for fractional value but that's straightforward.
> 
> In addition, you need to specify the handling of this attribute
> for the offer/answer and for the session annoucement case.
> E.g. for offer/answer multiple video-resolution attributes may
> be included since the two parties intend to negotiate a proper
> mode of operation.  For SAP announcements, however, the semantics
> are different.
> 
> I have concerns regarding section four though.  You are describing
> two different aspects there:
> 
> 1. notifying the receiver(s) about an upcoming change in the media
>    stream ("freeze picture")
> 
> 2. allowing the receiver(s) to instruct the sender to use a certain
>    repair mechanism.
> 
> You propose both to be implemented by means of SDP in the signaling
> path.  While I consent that the information carried are valuable
> and possibly required in certain scenarios, I am not sure that
> SDP carried in the signaling path is the right answer to your
> needs.
> 
> Item 1) could be looked at in two different ways: a picture freeze
> can be thought of something of longer duration which happens rather
> infrequently such as a mute operation (using a=inactive carried via
> SIP) for hold/unhold operations but I do not think that the area of
> application is really comparable.  In my opinion, what you want to
> do, is provide some kind of marker (possibly included in the media
> stream) that indicates that decoding shall stop until a certain
> condition (e.g. the intra frame from another source) is received.
> This seems highly video-specific and better be reasonably synchronized
> with the media stream.  SDP is definitely not an ideal option (what
> would you do if you not have a separate signaling path as in
> broadcasting applications).  RTCP is better but the information may
> not reach the receivers in a timely fashion; information contained
> within the media stream itself (or the RTP headers) migth be a
> better alternative (but I suspect that some religion may be
> involved here).
> 
> Item 2) is clearly related to the feedback work we have been doing.
> The primary issue seems to be that we prefer to provide "hints"
> to the other side while you prefer to call those hints "commands"
> and require the other side to act accordingly.  Again, I do not
> see SDP being a suitable candidate to carry this information;
> any such feedback via SDP is likely to take longer to reach the
> sender compared to using RTCP -- and if you have multiple commands
> to send, you are bound to one command per SIP transaction.
> 
> For item 2), I'd like to point out that SDP is also the wrong
> place from a semantics perspective.  Indicating a certain temporary
> receiver condition is fundamentally different from indicating a
> (change in a) media stream property; those two aspects should not
> be confused and hence different mechanisms should be applied here.
> 
> I'll be happy to try and find an RTP/RTCP-based solution but
> SDP is a bad idea for this.
> 
> Joerg
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 19 15:47:52 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01896
	for ; Wed, 19 Jun 2002 15:47:51 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24396;
	Wed, 19 Jun 2002 15:46:44 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24333
	for ; Wed, 19 Jun 2002 15:46:37 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01853;
	Wed, 19 Jun 2002 15:45:58 -0400 (EDT)
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 PAA15514;
	Wed, 19 Jun 2002 15:46:04 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03071;
	Wed, 19 Jun 2002 15:46:05 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Wed, 19 Jun 2002 15:46:05 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B553D@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Joerg Ott'" ,
        "Even, Roni"
	 
Cc: "'mmusic@ietf.org'" , "'avt@ietf.org'" 
Subject: RE: [AVT] Re: [MMUSIC] FWD: I-D ACTION:draft-even-mmusic-video-me
	dia-control-00.txt
Date: Wed, 19 Jun 2002 15:46:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

> Item 2) is clearly related to the feedback work we have been doing.
> The primary issue seems to be that we prefer to provide "hints"
> to the other side while you prefer to call those hints "commands"
> and require the other side to act accordingly.  Again, I do not
> see SDP being a suitable candidate to carry this information;
> any such feedback via SDP is likely to take longer to reach the
> sender compared to using RTCP -- and if you have multiple commands
> to send, you are bound to one command per SIP transaction.
> 
> For item 2), I'd like to point out that SDP is also the wrong
> place from a semantics perspective.  Indicating a certain temporary
> receiver condition is fundamentally different from indicating a
> (change in a) media stream property; those two aspects should not
> be confused and hence different mechanisms should be applied here.
> 
Seems like the problem here is reliability.  You need this "command"
to be reliable.  I'm not sure it has to be -very- reliable, but it
has to be more reliable than RTCP.  I think that is why sending it
in signalling was suggested.  Other suggestions for something more
reliable than RTCP are welcome, at least by me.

Brian

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 19 18:24:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05368
	for ; Wed, 19 Jun 2002 18:24:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02925;
	Wed, 19 Jun 2002 18:21:02 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02896
	for ; Wed, 19 Jun 2002 18:21:01 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05297
	for ; Wed, 19 Jun 2002 18:20:19 -0400 (EDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g5JMKsQ14082;
	Thu, 20 Jun 2002 00:20:54 +0200 (MEST)
Message-ID: <3D110426.EF8002C2@tzi.uni-bremen.de>
Date: Thu, 20 Jun 2002 00:22:30 +0200
From: Joerg Ott 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@ietf.org
CC: csp@isi.edu, mankin@isi.edu, sob@harvard.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] WG Last Call for draft-ietf-mmusic-sdp-comedia-03.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

we issue WG Last Call for Proposed Standard for

        draft-ietf-mmusic-sdp-comedia-03.txt

The Last Call is to expire in two weeks from on on 3 July 2002.
Please direct any comments to the MMUSIC mailing list.

Thanks,
Joerg

co-chair, MMUSIC

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 20 07:19:38 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25010
	for ; Thu, 20 Jun 2002 07:19:38 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13287;
	Thu, 20 Jun 2002 07:15:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13259
	for ; Thu, 20 Jun 2002 07:15:41 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24788
	for ; Thu, 20 Jun 2002 07:14:59 -0400 (EDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5KBFbrU026780;
	Thu, 20 Jun 2002 13:15:37 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id NAA27288; Thu, 20 Jun 2002 13:15:37 +0200
Message-ID: <3D11B958.3030005@era.ericsson.se>
Date: Thu, 20 Jun 2002 13:15:36 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jonathan Sergent 
CC: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> <3D0ED677.1060601@era.ericsson.se> <20020618090238.D11102@vernors.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Jonathan,

I have tried to write down the conclusions I have made from the 
discussion into specification text. The chapter below should be viewed 
in the context of the rest of what is written in chapter 9 of 
draft-ietf-mmusic-rfc2236bis-01.txt. Please comment on this text.

-----

9.3 The usage of connections

   TCP can be used for both persistent connections and for one message
   exchange  per  connection,  as  presented above. This section gives
   further rules and recommendations on how to  handle  these  connec-
   tions so maximum interoperability and flexibility can be achieved.

   A  server  SHALL  handle  both  persistent  connections   and   one
   request/response  transaction  per connection. A persistent connec-
   tion MAY be used  for  all  transactions  between  the  server  and
   client, including messages setup and teardown of multiple RTSP ses-
   sions. However the persistent connection MAY also be closed after a
   few message exchanges, e.g. the initial setup and play command in a
   session. Later when the client wishes to send a new  request,  e.g.
   pause,  to the session a new connection is opened.  This connection
   may either be for a single message exchange or can be kept open for
   several messages, i.e. persistent.

   The client MAY close the connection at any time when no outstanding
   request/response  transactions  exist.  The server SHOULD NOT close
   the connection unless at least one RTSP session timeout period  has
   passed  without  data traffic. A server MUST NOT close a connection
   directly after responding to a TEARDOWN request for the whole  ses-
   sion.

   The client SHOULD NOT have more than one connection to  the  server
   at any given point. If a client or proxy handles multiple RTSP ses-
   sions on the same server, it is RECOMMENDED to use  only  a  single
   connection.

-- 
Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 20 07:32:47 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25398
	for ; Thu, 20 Jun 2002 07:32:46 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13875;
	Thu, 20 Jun 2002 07:28:32 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA13839
	for ; Thu, 20 Jun 2002 07:28:30 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25256
	for ; Thu, 20 Jun 2002 07:27:47 -0400 (EDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5KBSNrU001207;
	Thu, 20 Jun 2002 13:28:23 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id NAA27642; Thu, 20 Jun 2002 13:28:23 +0200
Message-ID: <3D11BC57.7090009@era.ericsson.se>
Date: Thu, 20 Jun 2002 13:28:23 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: Jonathan Sergent 
CC: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> <3D0ED677.1060601@era.ericsson.se> <20020618090238.D11102@vernors.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Jonathan,

See comments below:

Jonathan Sergent wrote:

>
>Incoming connections will not use up server-side port numbers, since
>they will all be bound to port 554 (or whatever port the RTSP server is
>listening on) on the server side.
>
>There is still obviously a resource exhaustion issue if you mandate
>that the server never close the connection.  
>
>I do not know what the right behavior should be.  My gut feeling is
>that the client SHOULD attempt to reconnect to the server if it wants
>to send an RTSP command and it discovers that its connection has been
>lost.
>
I agree that the client must try to reconnect if the connection was lost.

>
>It's probably worthwhile to allow either the client or the server to
>request a "persistent connection" on a session with a feature tag that
>tells the other end to not shut down.  This feature tag, in addition to
>what has been proposed before, could also enforce a 1:1
>session-connection binding for the session and connection in question.
>If the client sent it to the server, it would tell the server to make
>the session and connection timeouts the same, and to always shut down
>the session if the connection goes away.  It would also tell the client
>not to shut down the connection during the middle of the session.  The
>server should be able to ask this of the client independently of
>whether the client has asked it of the server.  The server might want
>to request this if a clustering system was in use where the client
>might be reconnected to a different server.  So it should be able to
>tell the client "if you hang up the connection, I am going to terminate
>your session.
>
I don't know that having a feature tag for this will be useful. As far 
as I understand it neither side can really commit to having the 
connection open. Therefore it feels much more robust to assume that a 
client is free in its usage of persistent and non-persistent 
connections, and can at any point close a connection.

>
>This way we only have tightly-coupled session-connection binding, or
>no coupling at all, rather than a continuum of options.
>
I would rather argue for always having no coupling.

>
>The easiest thing for most typical media player clients will be to
>always request the option.
>
>But one can imagine applications where this is not desirable; for
>example, a client might send PLAY with the clock field set in the Range
>header to schedule a playout at some time in the future.  This could be
>used for a scheduled broadcast.  It would be undesirable to require
>that the TCP connection remain open until the broadcast actually
>starts, which might be several hours.  So it is worthwhile to allow
>clients to not request the 1:1 session-connection mapping.
>
The problem with the application your are describing is that it still 
requires the session to be kept alive, so traffic must regular be sent 
the server during these hours.

>
>
>P.S.  The server may also decide to drop client sessions and
>connections as a load shedding activity.  It would be helpful if this
>had well-defined meaning for the client so that the server can do this
>while still complying to the protocol.  The client could be required to
>expect that the server may want to refuse service to it after a stream
>has started playing.  I am not sure how useful it is to specify
>something like this.
>
I would recommend that load balancing is done at session setup time. 
However if the server really must move a stream it should use the 
REDIRECT method. I know that we still have problems with this in respect 
to non-persistent connections and UDP.

Regards


Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 20 07:44:41 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25746
	for ; Thu, 20 Jun 2002 07:44:41 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14938;
	Thu, 20 Jun 2002 07:43:58 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA14906
	for ; Thu, 20 Jun 2002 07:43:51 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25664
	for ; Thu, 20 Jun 2002 07:43:08 -0400 (EDT)
Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g5KBhfRb018046;
	Thu, 20 Jun 2002 13:43:41 +0200 (MEST)
Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T))
	id NAA28097; Thu, 20 Jun 2002 13:43:40 +0200
Message-ID: <3D11BFEC.4040605@era.ericsson.se>
Date: Thu, 20 Jun 2002 13:43:40 +0200
From: Magnus Westerlund 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
MIME-Version: 1.0
To: venaraya@npd.hcltech.com
CC: "mmusic@ietf.org" 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References:  <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors> <3D0ED677.1060601@era.ericsson.se> <3D0F2466.DCC7D8DF@npd.hcltech.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Venkat,

Thanks for the TCP keep alive information. As I have written in my 
suggested specification text a connection seeing no traffic for a RTSP 
timeout period may be closed by the server. However I would strongly 
recommend that servers would use a bigger timeout. As long as the 
resource situation for the server is not severe there exist no reason 
for the server to timeout a connection.  There exist two good reasons 
for keeping the connections alive, first the server to client requests 
can be used, secondly any request goes faster as it save the 1.5 RTT it 
takes to set up a TCP connection.

I don't think we need special keep alive traffic for the connection as 
the RTSP methods can be used. That also has the advantage of keeping 
also the RTSP session alive.

Regards

Magnus

Venkat N wrote:

> Hi Magnus ,
>
> There are two things we could consider here :
>
> 1.
> I presume that most  application protocols like ftp  implement
> timeouts  in such a way that a crossing of a particular time-period
> would imply  closing the connection (i.e if nothing comes from the client
> then it is as good as connection closed ).
>
> 2. If the  connnection has to be maintained  for a long time period then
>    there arises a possibility of using SO_KEEPALIVE .
>    On linux  systems this is present in the file 
> proc/sys/net/ipv4/tcp_keepalive_time
>    and defaults to  7200 secs .
>   This seems too big a value  and would affect all TCP connections 
> with the
>    option set.
>  
>
> Another possibility could be a mechanism running btn client
> and server for maintaining the connections.The drawback
> with this approach is that it may not be applicable to
> all clients as the protocol or mechanism is only between
> a particular client and server .
>
> It looks to me that keeping the connection open for sending
> a subsequent "SETUP" request is definitely an advantage
> but we also need to consider the polling done by the server
> on all the connected filedescriptors. If there are 100 connections
> to a server and 90 of them are idle for a long time then this
> would amount to clogging the system resources.
>
> So deciding on the timeout is still a question and my  view is that 
> the connection
> need not remain open if there is no transmission of data .
>  
>
>-- 
> Regards,
>-Venkat
>
>Visit http://cdn.hcltech.com/
>
>  


-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson Radio Systems AB  | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Mon Jun 24 02:33:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23523
	for ; Mon, 24 Jun 2002 02:33:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA22690;
	Mon, 24 Jun 2002 02:29:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA12453
	for ; Mon, 24 Jun 2002 01:03:35 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13146;
	Mon, 24 Jun 2002 01:02:51 -0400 (EDT)
Received: from mira-sjc5-9.cisco.com (IDENT:mirapoint@mira-sjc5-9.cisco.com [171.71.163.32])
	by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5O533dg010646;
	Sun, 23 Jun 2002 22:03:03 -0700 (PDT)
Received: from cj14 (ssh-sjc-1.cisco.com [171.68.225.134])
	by mira-sjc5-9.cisco.com (Mirapoint)
	with SMTP id ADF68914;
	Sun, 23 Jun 2002 22:03:09 -0700 (PDT)
From: "Cullen Jennings" 
To: "Even, Roni" , 
Cc: 
Date: Sun, 23 Jun 2002 22:04:37 -0700
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: 
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] RE: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-00.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit


few things I noticed on a quick read ....

Limiting xmax and ymax to 3 digits seems like a bad idea given there are
video cameras that support 1024 and above.

The ABNF for the mpi does not seem so support fractional values such at 10.5

IMHO  the video-frame stuff should be a separate draft.

Cullen

> -----Original Message-----
> From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of
> Even, Roni
> Sent: Wednesday, June 12, 2002 1:50 AM
> To: mmusic@ietf.org
> Cc: avt@ietf.org
> Subject: [AVT] FWD: I-D
> ACTION:draft-even-mmusic-video-media-control-00.txt
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 	Title : SDP attributes for Video media Media Control
> 	Author(s) : R. Even, O. Levin, P. Koskelainen
> 	Filename : draft-even-mmusic-video-media-control-00.txt
> 	Pages : 6
> 	Date : 10-Jun-02
> This document defines the syntax and the semantics for the new SDP
> attributes required for handling of video. These attributes are not CODEC
> specific.
>
> A URL for this Internet-Draft is:
> 
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-even-mmusic-video-media-control-00.txt".

A list of Internet-Drafts directories can be found in
 or





_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Mon Jun 24 04:34:48 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25913
	for ; Mon, 24 Jun 2002 04:34:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29676;
	Mon, 24 Jun 2002 04:33:53 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA29629
	for ; Mon, 24 Jun 2002 04:33:50 -0400 (EDT)
Received: from accord-ntsrv3.accord.co.il ([212.199.61.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25845;
	Mon, 24 Jun 2002 04:33:05 -0400 (EDT)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id ; Mon, 24 Jun 2002 11:33:15 +0300
Message-ID: 
From: "Even, Roni" 
To: "'Cullen Jennings'" ,
        "Even, Roni"
	 , mmusic@ietf.org
Cc: avt@ietf.org
Date: Mon, 24 Jun 2002 11:31:29 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="windows-1255"
Subject: [MMUSIC] RE: [AVT] FWD: I-D ACTION:draft-even-mmusic-video-media-control-0
 0.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Cullen,

I can update the xmax and ymax size and will fix the ABNF.
As for having a different draft, the reason we put it together is because we
want to have all the needed video attributes in one draft and have video
media attributes as a working group item. So if you think that "video frame
stuff" is not an important video issue then explain
Thanks
Roni Even


> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Monday, June 24, 2002 8:05 AM
> To: Even, Roni; mmusic@ietf.org
> Cc: avt@ietf.org
> Subject: RE: [AVT] FWD: I-D
> ACTION:draft-even-mmusic-video-media-control-00.txt
> 
> 
> 
> few things I noticed on a quick read ....
> 
> Limiting xmax and ymax to 3 digits seems like a bad idea 
> given there are
> video cameras that support 1024 and above.
> 
> The ABNF for the mpi does not seem so support fractional 
> values such at 10.5
> 
> IMHO  the video-frame stuff should be a separate draft.
> 
> Cullen
> 
> > -----Original Message-----
> > From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of
> > Even, Roni
> > Sent: Wednesday, June 12, 2002 1:50 AM
> > To: mmusic@ietf.org
> > Cc: avt@ietf.org
> > Subject: [AVT] FWD: I-D
> > ACTION:draft-even-mmusic-video-media-control-00.txt
> >
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > 	Title : SDP attributes for Video media Media Control
> > 	Author(s) : R. Even, O. Levin, P. Koskelainen
> > 	Filename : draft-even-mmusic-video-media-control-00.txt
> > 	Pages : 6
> > 	Date : 10-Jun-02
> > This document defines the syntax and the semantics for the new SDP
> > attributes required for handling of video. These attributes 
> are not CODEC
> > specific.
> >
> > A URL for this Internet-Draft is:
> >  -control-0
> 0.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-even-mmusic-video-media-control-00.txt".
> 
> A list of Internet-Drafts directories can be found in
>  or
> 
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 26 17:38:35 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12184
	for ; Wed, 26 Jun 2002 17:38:35 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01208;
	Wed, 26 Jun 2002 17:28:12 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA01177
	for ; Wed, 26 Jun 2002 17:28:10 -0400 (EDT)
Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11746
	for ; Wed, 26 Jun 2002 17:27:21 -0400 (EDT)
Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1])
	by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g5QLRxt07713;
	Wed, 26 Jun 2002 23:27:59 +0200 (MEST)
Message-ID: <3D1A323C.62A9AD4C@tzi.uni-bremen.de>
Date: Wed, 26 Jun 2002 23:29:32 +0200
From: Joerg Ott 
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mmusic@ietf.org
CC: csp@isi.edu, sob@harvard.edu, mankin@isi.edu
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] MMUSIC meeting in Yokohama
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Folks,

we have a single MMUSIC meeting tentatively scheduled for

        Thursday, 18 July 2002, 0900 - 1130

Agenda slot requests are solicited on the following
subjects (and other areas within the charter of MMUSIC):

- RTSP
- SDP and fixes/chartered extensions
- SDPng

Please direct agenda requests directly to

       csp@isi.edu
       jo@ipdialog.com

We have already received a few requests and would like to
collect further ones until the middle of next week.

Please remember that meeting slots are meant for discussing
and resolving issues, not for presentations of ideas.
Any slot request MUST at least be backed by an Internet Draft
that has received attention in the past and for which issues
need to be resolved.  It would be helpful if you could outline
the issues to be addressed in you slot request(s).

Thanks,
Joerg

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Wed Jun 26 18:01:20 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13110
	for ; Wed, 26 Jun 2002 18:01:20 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02579;
	Wed, 26 Jun 2002 17:53:24 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02530
	for ; Wed, 26 Jun 2002 17:53:21 -0400 (EDT)
Received: from mail3.dynamicsoft.com ([63.113.44.69])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12721;
	Wed, 26 Jun 2002 17:52:36 -0400 (EDT)
Received: from dynamicsoft.com ([63.113.46.192])
	by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g5QLliYH023194;
	Wed, 26 Jun 2002 17:47:46 -0400 (EDT)
Message-ID: <3D1A367D.2050205@dynamicsoft.com>
Date: Wed, 26 Jun 2002 17:47:41 -0400
From: Jonathan Rosenberg 
Organization: dynamicsoft
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Even, Roni" 
CC: "'Joerg Ott'" ,
        "'mmusic@ietf.org'"
 ,
        "'avt@ietf.org'" 
Subject: Re: [MMUSIC] FWD: I-D  ACTION:draft-even-mmusic-video-media-contr
  ol-00.txt
References: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

inline.

Even, Roni wrote:
> Hi Joerg,
> Thanks for your comments.
> 
> 1. About the BNF I will fix it.
> 
> 2. I thought of having a section describing the usage in SIP and SAP but
> noticed that other drafts like offer/answer and simple capabilities do
> not
> have section about SIP usage. If you meant that you want to explain how
> the
> encoder uses this attribute to select the mode of operation I can add
> this
> 
> 3. About fast update and freeze. 
> 	3.1 Using RTCP feedback for update was discussed in the last
> meeting
> and I agreed with the AVT guys that this should not be there
> 	3.2 I would like to look at the new picture and freeze picture
> in
> the same context as a new codec request. This means that we use
> signalling
> to ask for a new codec and I see this feature as the same since I am
> asking
> for the same codec but with a new picture. If you want to look at it
> from
> the decoder wants a new codec or a new picture. Since changing a codec
> during a session is working in SAP and in SIP I do not see the problem

THe problem is that the new picture request, in particular, is not a 
change in STATE of the session, its a command to send a new picture. The 
SDP and offer/answer stuff is appropriate where there is a change in 
state of the session parameters. That is not the case here. I also 
suspect latency is an issue, since the video is distorted until you get 
the new intra picture. So it would seem to argue for a media path thing. 
Latency is generally not an issue for things like codec change and hold.

The new picture request is a lot like things such as camera controls, 
which are real-time media stream control activities. I am inclined to 
argue that the appropriate solution is an e2e control protocol that, 
like a media stream, is signaled in the SDP. We've argued that the same 
is true for thigns like floor control.

Freeze picture request does seem like its a lot like hold. Its a 
persistent state of the session, and it must be explicitly changed to 
get off of "freeze". Thus, I think an SDP approach here is fine.

-Jonathan R.



-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 01:36:23 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23780
	for ; Thu, 27 Jun 2002 01:36:22 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02034;
	Thu, 27 Jun 2002 01:30:43 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02001
	for ; Thu, 27 Jun 2002 01:30:41 -0400 (EDT)
Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23653
	for ; Thu, 27 Jun 2002 01:29:55 -0400 (EDT)
Received: from real.com (murrow2k1.real.com [207.188.7.41])
	by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g5R5TxKR027267;
	Wed, 26 Jun 2002 22:29:59 -0700
Received: from A7397.real.com (dsl081-021-089.sea1.dsl.speakeasy.net [64.81.21.89])
	by real.com (8.12.2/8.12.2) with ESMTP id g5R5TwMB021321;
	Wed, 26 Jun 2002 22:29:59 -0700
Message-Id: <5.1.0.14.2.20020626220426.0318fc98@mail.real.com>
X-Sender: jworley@mail.real.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 26 Jun 2002 22:20:34 -0700
To: Magnus Westerlund ,
        Jonathan Sergent 
From: Jeremy Worley 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
Cc: "mmusic@ietf.org" 
In-Reply-To: <3D11BC57.7090009@era.ericsson.se>
References: 
 <3D0D88FA.8040504@era.ericsson.se>
 <20020617083604.D29124@vernors>
 <3D0ED677.1060601@era.ericsson.se>
 <20020618090238.D11102@vernors.eng.sun.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Magnus, Jonathan,

At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:
>>It's probably worthwhile to allow either the client or the server to
>>request a "persistent connection" on a session with a feature tag that
>>tells the other end to not shut down.  This feature tag, in addition to
>>what has been proposed before, could also enforce a 1:1
>>session-connection binding for the session and connection in question.
>>If the client sent it to the server, it would tell the server to make
>>the session and connection timeouts the same, and to always shut down
>>the session if the connection goes away.  It would also tell the client
>>not to shut down the connection during the middle of the session.  The
>>server should be able to ask this of the client independently of
>>whether the client has asked it of the server.  The server might want
>>to request this if a clustering system was in use where the client
>>might be reconnected to a different server.  So it should be able to
>>tell the client "if you hang up the connection, I am going to terminate
>>your session.

I'm inclined to agree with Jonathan that a feature tag is desirable.  If a 
server can choose to terminate the RTSP session, forcing the client to 
reconnect to send a message, then there are cases where the cost of 
reconnect may be too high.  For example, a general purpose RTSP server on 
the internet and a client on a high-latency network.  The server on the 
internet may be configured to not maintain persistent sessions by default, 
assuming most sessions will be over low latency links.  The client, being 
on a high latency network, would prefer a persistent session. In this case, 
signalling a preference for a persistent RTSP session could be beneficial.

There may also be cases where the server would want to signal this.

>I don't know that having a feature tag for this will be useful. As far as 
>I understand it neither side can really commit to having the connection 
>open. Therefore it feels much more robust to assume that a client is free 
>in its usage of persistent and non-persistent connections, and can at any 
>point close a connection.

I don't understand why neither side can commit to having the connection 
open.  I think that if both sides agree to a persistent connection, then 
defining rules for coupling of RTSP and RTP sessions should be OK.

Regards,
         Jeremy


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 02:03:11 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28482
	for ; Thu, 27 Jun 2002 02:03:11 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA03008;
	Thu, 27 Jun 2002 01:58:17 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02980
	for ; Thu, 27 Jun 2002 01:58:15 -0400 (EDT)
Received: from hclnpd.hclt.co.in ([202.54.64.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24189
	for ; Thu, 27 Jun 2002 01:57:29 -0400 (EDT)
Received: from mailnpd.hclt-ntl.co.in ([192.168.19.36]) by hclnpd.hclt.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id MR125BBS; Thu, 27 Jun 2002 11:27:05 +0530
Received: from npd.hcltech.com (gayramak-pc.hclt-ntl.co.in [192.168.19.77])
	by mailnpd.hclt-ntl.co.in (8.11.0/8.11.0) with ESMTP id g5R5mmL11067
	for ; Thu, 27 Jun 2002 11:18:48 +0530
Message-ID: <3D1AAA72.CAFFB70A@npd.hcltech.com>
Date: Thu, 27 Jun 2002 11:32:26 +0530
From: Gayathri Ramakrishnan 
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF MMUSIC WG 
Content-Type: multipart/mixed;
 boundary="------------31ED553164B8C29CEEF912BB"
Subject: [MMUSIC] Review of Section 10 - RTSP Feature table
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

This is a multi-part message in MIME format.
--------------31ED553164B8C29CEEF912BB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Attached is the reviewed Section 10 of the
RTSP Feature matrix.  Comments for some of
them are included inline.

I also have some general queries (see
towards the end of the doc). Pl clarify 
the same.

Thanks,
Gayathri
-- 
We pause, to soar higher.
http://cdn.hcltech.com
--------------31ED553164B8C29CEEF912BB
Content-Type: text/plain; charset=us-ascii;
 name="feature-matrix.txt"
Content-Disposition: inline;
 filename="feature-matrix.txt"
Content-Transfer-Encoding: 7bit

SRV=Server
PRY=Proxy
CLT=Client

Keys for requirements explicitly callout
M=MUST
MN=MUST NOT
SD=SHOULD
SDN=SHOULD NOT
SL=SHALL
SLN=SHALL NOT
MAY=MAY
NA=NOT APPLICABLE
OPT=OPTIONAL
REQ=REQUIRED
REC=RECOMMENDED

Keys for requirements implicitly callout
m=must
mn=must not
sd=should
sdn=should not
sl=shall
sln=shall not
may=may
na=not applicable
opt=optional
req=required
rec=recommended

Other Keys
desc=describe
para=parameter
mthd=method
recd=recording
conf=conference
info=information
pres=presentation
attr=attribute
app=application
init=initialization
id=identifier
req=required
diff=different
avail=available
sync=synchronize
auth=authenticate


  LINE FEATURE SUMMARY                         SECTION         SRV PRY CLT
  1656request may be issued at any time       10.1 OPTIONS    may may may
      **Proxy may be able to send OPTIONS
        request on behalf of the client or
	on its own in case of multicast??
  1657It does not influence SRV state.        10.1 OPTIONS    must info info
  1688retrieves desc.                         10.2 DESCRIBE   info info info
  1690Accept header to specify desc. formats  10.2 DESCRIBE   na    may  may
  1691SRV responds withdesc.                  10.2 DESCRIBE   must  -    -
  1692reply-response pair constitutes media   10.2 DESCRIBE   init init init
      ** The RFC could be modified to call
         this as request-response pair.
  1721MUST contain all media init.            10.2 DESCRIBE   M    M     M
  1722info. for resource(s)it describes       10.2 DESCRIBE   req  -    -
  1723fromsource or than DESCRIBE             10.2 DESCRIBE   may  may  may
  1724containscomplete set of media init.     10.2 DESCRIBE   may  may  may
  1725CLT SHOULD use those para.              10.2 DESCRIBE   SD   SD   SD
  1729of media indirection.                   10.2 DESCRIBE   SDN  SDN  SDN
      ** Could be changed to
      ** SHOULD NOT DESCResp of media 
      ** indirection
  1732  unambiguous means of knowing          10.2 DESCRIBE   -  req  req
  1742contain all media init. for set of strea10.2 DESCRIBE
  1743discouraging use of DESCRIBE for media i10.2 DESCRIBE   rec rec rec
  1744avoid looping problems                  10.2 DESCRIBE   must must must
  1747  Media init. isrequirement             10.2 DESCRIBE   req req req
  1748does not dictatemust be done            10.2 DESCRIBE   m   m  m
  1752  * via RTSP's DESCRIBE mthd;           10.2 DESCRIBE   may  may  may
  1753  * via some or protocol (HTTP, email at10.2 DESCRIBE   may  may  may
  1754  * via command line or standard input  10.2 DESCRIBE   may  may  may
  1759recommendedminimal SRVs support         10.2 DESCRIBE   rec rec rec
  1760recommendedminimal CLTs support         10.2 DESCRIBE   rec rec rec
  1761acceptsmedia init. file                 10.2 DESCRIBE   rec rec rec
  1762  from standard input, command line, and10.2 DESCRIBE   rec rec rec
  1769posts desc.                             10.3 ANNOUNCE   must must must
  1770media object identified by request URL  10.3 ANNOUNCE   must must must
  1771updates session desc.                   10.3 ANNOUNCE   must must must
  1775whole pres desc. should be sent         10.3 ANNOUNCE   sd   sd   sd
  1776rarther than just additional components 10.3 ANNOUNCE

  1813request forURI specifies transport mecha10.4 SETUP      m    m    m 
  1815can issue a SETUP request for a                         may  may  may 
      stream that is already playing 
  1816 Server MAY allow                       10.4 SETUP      MAY  na   na 
    *** Here 1815 condition is split into 
    *** two different conditions. 
  1816If it does not allow this, it MUST respo10.4 SETUP      MAY  MAY  MAY 
      error "455 mthd Not Valid In State" 
    *** This condition could be combined 
    *** with 1817. Is there any specific 
    *** reason to say both MUST and MAY for 
    *** this case? Or MMAY should be 
    *** interpreted differently. 
  1818intervening firewalls,CLT must indicate 10.4 SETUP      na   m    m 
  1822  Since SETUP includes all transport ini10.4 SETUP      na   m    m 
  1828specifies transport para. acceptable    10.4 SETUP      req  req  req 
  1829CLT for data transmission               10.4 SETUP      n/a  req  req 
  1830transport para. selected by SRV.        10.4 SETUP      req  req  na 
  1843SRV generates session id.s              10.4 SETUP      m    na   na 
  1845 SRV MUST bundle setup request          10.4 SETUP      M    na   na 
  1854return error "459 agg. Operation Not All10.4 SETUP      M    ?    na 
  1859tells SRV to start sending data         10.5 PLAY       m    m    m 
  1861SETUP requests have been acknowledged   10.5 PLAY       na   MN   MN 
    *** Could this condition be considered 
    *** as explicit callout MUSTNOT. 
  1864positions normal play time to beginning 10.5 PLAY       m    na   m 
  1865delivers stream data until end          10.5 PLAY       m    m    na 
  1866requests may be pipelined (queued)      10.5 PLAY       may  na   na 
  1867MIUST queue PLAY requests to be executed10.5 PLAY       M    M    M 
  1869delayed until first has been completed. 10.5 PLAY       m    na   na 
  1871allows precise editing.                 10.5 PLAY       info info info 
  1895PLAY request without Range header legal 10.5 PLAY       m    m    m 
  1896beginning unless stream has been paused 10.5 PLAY       m    m    na 
  1897paused via PAUSE, stream delivery resume10.5 PLAY       m    m    na 
  1899can be used by CLT to test SRV liveness.10.5 PLAY       may  may  may 
  1910containt time parameter                 10.5 PLAY       may  may  may 
  1911specifies time in UTC                   10.5 PLAY       sd   sd   sd 
  1912msgreceived after specified time        10.5 PLAY       m    na   na 
  1913aid sync of streams obtained from 
     diff sources.                            10.5 PLAY       may  may  may 
    *** 1913 and 1914 together indicates 
    *** sync. So they could be combined. 
  1916SRV replies with actual range           10.5 PLAY       m    m    na 
  1918 resp range may differ from requested 
       range                                  10.5 PLAY       may  may  may 
    *** This line could be included instead 
    *** of 'allignment of requested range 
    *** to valid frame' 
  1920current position returned in reply      10.5 PLAY       m    ?    na 
  1921unit range in reply same as in request. 10.5 PLAY       req  req  na 
  1923pres automatically pause                10.5 PLAY       m    m    na 
  1941live desirable to use clock units:      10.5 PLAY       rec  rec  rec 
  1952only supporting playback MUST support np10.5 PLAY       M    M    M 
  1953MAY support clock and smpte formats.    10.5 PLAY       MAY  MAY  MAY 


  1968stream delivery to be interrupted       10.6 PAUSE      m    m    m
      ** Capability of the client to stop
      ** stream delivery has been
      ** interpreted as an implicit 'must'
      ** for client
  1970playback and recd ofstream halted       10.6 PAUSE      m    m    m
  1973group halted                            10.6 PAUSE      m    m    m
  1974sync of tracks MUST                     10.6 PAUSE      M    M    M
  1975SRV resources are kept                  10.6 PAUSE      MAY  MAY  MAY
  1976session and free resources after being p10.6 PAUSE      sd   sd   sd
  1977specified with timeout parameter of Sess10.6 PAUSE      sd   sd   sd
  1990request may contain Range header        10.6 PAUSE      may  may  may
  1992pause point must contain one value      10.6 PAUSE      M    M    M
      ** This could be changed to an explicit
      ** MUST in the RFC too.
  1993normal play time for stream set to pause10.6 PAUSE      m    m    m
  1995pause effective encounting timepoint    10.6 PAUSE      m    m    m
  1997If time outside ? error "457 Invalid Ran10.6 PAUSE      M    M    M
  1999starts at pause point, not played or rec10.6 PAUSE      
  2000Range header missing, interrupted immedi10.6 PAUSE      m    m    m
  2002pause point set to current normal play t10.6 PAUSE      m    m    m
  2004request discards all queued PLAY        10.6 PAUSE      m    m    m
  2005point in media stream MUST be maintained10.6 PAUSE      M    M    M
  2006subsequent PLAY resumes pause point.    10.6 PAUSE      m    m    m
  2032If SRV sent data beyond Range header    10.6 PAUSE      
  2033PLAY would still resume at point in time10.6 PAUSE      m    m    m
  2034assumed CLT has discarded data          10.6 PAUSE      m    m    m
  2035ensures continuous pause/play cycling   10.6 PAUSE      info info info
      ** Another keyword called 'conclusion'
      ** could be included in the list which
      ** can be used for this case.
  2039stops stream delivery for given URI,    10.7 TEARDOWN   m    m    m
  2040freeing resources associated            10.7 TEARDOWN   m    m    m
  2041URI is pres URI session id. invalid     10.7 TEARDOWN   m    m    m
  2043all transport defined session desc.     10.7 TEARDOWN
  2044SETUP request before played again.      10.7 TEARDOWN   m    m    m
  2055retrieves value specified in URI        10.8 GET_PARAME req  req  req
  2057content of reply left to implementation 10.8 GET_PARAME Left to the application
  2058no entity body may test liveness ("ping"10.8 GET_PARAME may  may  may


  2093requests value for a URI                10.9 SET_PARAME req  req req
  2096contain single parameter to determine re10.9 SET_PARAME SD  SD   SD
  2098several act if all para. successfully   10.9 SET_PARAME M   M    M
  2100allow to set repeatedly to same value   10.9 SET_PARAME M   M    M
  2101disallow changing parameter values.     10.9 SET_PARAME MAY MAY  MAY
  2103transport para. set with SETUP          10.9 SET_PARAME M   M    M
  2109split in fine-grained for error indicati10.9 SET_PARAME may may  may
  2111an atomic settings is desirable         10.9 SET_PARAME opt opt  opt
  2147informs CLT connect another SRV         10.10 REDIRECT  m   m    m
  2148mandatory header Location               10.10 REDIRECT  m   m    m
  2150Range indicates redirection takes effect10.10 REDIRECT  may may  may
  2152continue send receive TEARDOWN request  10.10 REDIRECT  M   M    M
  2153SETUP new session at designated host    10.10 REDIRECT  M   M    M
  2166recd range according desc.              10.11 RECORD    m   m    m
  2167timestamp reflects start and end time   10.11 RECORD    sd  sd   sd
  2168no time range given use start or end tim10.11 RECORD    req req  req
  2170If started, commence recd immediately.  10.11 RECORD    m   m    m
  2172recorded data under the request-uri     10.11 RECORD    opt opt  opt
      ** that the server optionally
      ** uses the user specified uri
  2172recorded data request or another URI    10.11 RECORD    m   m    m
      ** The server must record either in the
      ** uri location mentioned by the user
      ** or another uri

  2174not use request URI response 201        10.11 RECORD    SD  SD   SD
  2175describes status of request             10.11 RECORD    SD  SD   SD 
  2176refers new resource and Location        10.11 RECORD    SD  SD   SD 
  2178media SRV supporting recd of live press 10.11 RECORD    M   M    M
  2179recd live must support clock range forma10.11 RECORD    M   M    M
      ** The above two lines can be combined
      ** into a single line.
      ** A media server supporting recording
      ** of live presentations MUST support the
      ** clock range format

  2201interleave RTSP mthds and stream data   10.12 Interleav may may  may  
  2202interleaving should generally avoided   10.12 Interleav sd  sd   sd
  2204SHOULD be used RTSP carried over TCP.   10.12 Interleav SD  SD   SD
  2206encapsulated by an ASCII dollar sign    10.12 Interleav m   m    m
  2207followed byone-byte channel id.,        10.12 Interleav m   m    m
  2208followed by length of binary data       10.12 Interleav m   m    m
  2209two-byte integer in network byte order  10.12 Interleav m   m    m
  2210stream data immediately without CRLF    10.12 Interleav m   m    m
  2211Each $ block contains one upper-layer   10.12 Interleav m   m    m
  2214channel id.defined in Transport header  10.12 Interleav infoinfo info
  2217When RTP, RTCP msgs are interleaved     10.12 Interleav sd  sd   sd
  2219RTCP sent first avail higher than RTP   10.12 Interleav sd  sd   sd 
  2220MAY request RTCP packets another channel10.12 Interleav MAY MAY  MAY
  2221two channels in interleaved of Transport10.12 Interleav req req  req
  2224RTCP sync two or more streams           10.12 Interleav req req  req 
  2226tunnel RTP/RTCP through TCP connection  10.12 Interleav infoinfo info
  2227transfer onto UDP                       10.12 Interleav sd  sd   sd




Some general comments / queries :

 1.A PLAY request without a Range header is legal. It starts playing a 
   stream from the beginning unless the stream has been paused. If a 
   stream has been paused via PAUSE, stream delivery resumes at the 
   pause point. If a stream is playing, such a PLAY request causes no 
   further action and can be used by the client to test server liveness.


   Lets consider this scenario 
	* The client wants to play the entire movie once again. 
	immediately after the first PLAY is over 
	* It sends a PLAY request without the Range header 
	while the first PLAY is still playing. 
  

In this case it would be treated as a 'ping' to test the 
server liveliness. Is it possible to have a machanism 
to differentiate between the request that could be 
used as a 'ping' and a request to play the entire movie 
once again??

BTW, What is meant by precise editing? 


2. Is it possible for a 'PAUSE' request to contain a Range header with the
   value (i.e pause point) greater than the value that has actually been
   played out ?

   For eg. if a 'PLAY' has been issued for range '10 - 20' and media has
   played say upto '15' then, is it possible by any of the media client to 
   send a 'PAUSE' request with a 'Range' header value of '18' ???

   If the above is possible and is valid, then once the 'PAUSE' request for
   the above is recd., do we finish playing the media upto '18' and then 
   pause ???

 


--------------31ED553164B8C29CEEF912BB--


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 03:02:39 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04248
	for ; Thu, 27 Jun 2002 03:02:39 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05651;
	Thu, 27 Jun 2002 02:54:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA05618
	for ; Thu, 27 Jun 2002 02:54:53 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04024
	for ; Thu, 27 Jun 2002 02:54:09 -0400 (EDT)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5R6seRb007484
	for ; Thu, 27 Jun 2002 08:54:40 +0200 (MEST)
Received: from era.ericsson.se
 (research-nnng7k.ki.sw.ericsson.se [147.214.34.108])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GYC003B3R74IX@mbb1.ericsson.se> for mmusic@ietf.org; Thu,
 27 Jun 2002 08:54:40 +0200 (MET DST)
Date: Thu, 27 Jun 2002 08:54:40 +0200
From: Magnus Westerlund 
Subject: Re: [MMUSIC] Review of Section 10 - RTSP Feature table
To: Gayathri Ramakrishnan 
Cc: IETF MMUSIC WG 
Message-id: <3D1AB6B0.2090602@era.ericsson.se>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
 Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
References: <3D1AAA72.CAFFB70A@npd.hcltech.com>
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

Lets start with the general comments.

>
>Some general comments / queries :
>
> 1.A PLAY request without a Range header is legal. It starts playing a 
>   stream from the beginning unless the stream has been paused. If a 
>   stream has been paused via PAUSE, stream delivery resumes at the 
>   pause point. If a stream is playing, such a PLAY request causes no 
>   further action and can be used by the client to test server liveness.
>
>
>   Lets consider this scenario 
>	* The client wants to play the entire movie once again. 
>	immediately after the first PLAY is over 
>	* It sends a PLAY request without the Range header 
>	while the first PLAY is still playing. 
>  
>
>In this case it would be treated as a 'ping' to test the 
>server liveliness. Is it possible to have a mechanism 
>to differentiate between the request that could be 
>used as a 'ping' and a request to play the entire movie 
>once again??
>
The use of PLAY for pinging the server about liveness will be 
deprecated. Instead the other methods for this should be use, RTCP, 
PING, SET_PARAMETER, or OPTIONS.

We are currently leaning towards removing queued play. This is primarily 
due to lacking any valid use case for queued play. Without queued play 
you can't request the movie again until it has played to end and the 
client issues a PAUSE followed by a PLAY.

>
>BTW, What is meant by precise editing? 
>
I believe the mentioning of precise editing was due to the fact that you 
could by a series of play requests could create an edited version of 
 the media (requires queued play).

>
>
>2. Is it possible for a 'PAUSE' request to contain a Range header with the
>   value (i.e pause point) greater than the value that has actually been
>   played out ?
>
Yes, as long as it contains a range which is part of the range that 
actually is requested to be played.

>
>   For eg. if a 'PLAY' has been issued for range '10 - 20' and media has
>   played say upto '15' then, is it possible by any of the media client to 
>   send a 'PAUSE' request with a 'Range' header value of '18' ???
>
>   If the above is possible and is valid, then once the 'PAUSE' request for
>   the above is recd., do we finish playing the media upto '18' and then 
>   pause ???
>
Yes, you are correct. This is exactly what is possible with PAUSE with 
range header.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 03:21:10 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04519
	for ; Thu, 27 Jun 2002 03:21:10 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07102;
	Thu, 27 Jun 2002 03:20:35 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07028
	for ; Thu, 27 Jun 2002 03:20:32 -0400 (EDT)
Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04498
	for ; Thu, 27 Jun 2002 03:19:48 -0400 (EDT)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5R7KVRb014918
	for ; Thu, 27 Jun 2002 09:20:31 +0200 (MEST)
Received: from era.ericsson.se
 (research-nnng7k.ki.sw.ericsson.se [147.214.34.108])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GYC00C2PSE7OJ@mbb1.ericsson.se> for mmusic@ietf.org; Thu,
 27 Jun 2002 09:20:31 +0200 (MET DST)
Date: Thu, 27 Jun 2002 09:20:31 +0200
From: Magnus Westerlund 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
To: Jeremy Worley 
Cc: "mmusic@ietf.org" 
Message-id: <3D1ABCBF.7090705@era.ericsson.se>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
 Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
References: 
 <3D0D88FA.8040504@era.ericsson.se> <20020617083604.D29124@vernors>
 <3D0ED677.1060601@era.ericsson.se> <20020618090238.D11102@vernors.eng.sun.com>
 <5.1.0.14.2.20020626220426.0318fc98@mail.real.com>
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Jeremy,

See my comments below.

Jeremy Worley wrote:

> Magnus, Jonathan,
>
> At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:
>
>>> It's probably worthwhile to allow either the client or the server to
>>> request a "persistent connection" on a session with a feature tag that
>>> tells the other end to not shut down.  This feature tag, in addition to
>>> what has been proposed before, could also enforce a 1:1
>>> session-connection binding for the session and connection in question.
>>> If the client sent it to the server, it would tell the server to make
>>> the session and connection timeouts the same, and to always shut down
>>> the session if the connection goes away.  It would also tell the client
>>> not to shut down the connection during the middle of the session.  The
>>> server should be able to ask this of the client independently of
>>> whether the client has asked it of the server.  The server might want
>>> to request this if a clustering system was in use where the client
>>> might be reconnected to a different server.  So it should be able to
>>> tell the client "if you hang up the connection, I am going to terminate
>>> your session.
>>
>
> I'm inclined to agree with Jonathan that a feature tag is desirable.  
> If a server can choose to terminate the RTSP session, forcing the 
> client to reconnect to send a message, then there are cases where the 
> cost of reconnect may be too high.  For example, a general purpose 
> RTSP server on the internet and a client on a high-latency network.  
> The server on the internet may be configured to not maintain 
> persistent sessions by default, assuming most sessions will be over 
> low latency links.  The client, being on a high latency network, would 
> prefer a persistent session. In this case, signalling a preference for 
> a persistent RTSP session could be beneficial.

>
> There may also be cases where the server would want to signal this.

Yes, I agree with the motivations you give above. However I don't see 
how a feature tag will help. The problem of when the server shall close 
the connection and recover the resources related to the connection still 
remains. If the client sends a feature tag saying it want to have a 
persistent connection and then the server receives no messages. When are 
the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, 
or never? To solve this problem I suggest that the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic. See text proposal for a section 9.3 in mmusic 
message:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.html

If the server does not close unless a RTSP time-out time has passed the 
client has the choice to keep a persistent connection. It simply has to 
maintain it by sending a message normally at least every 60 seconds, 
these messages can also be used to keep the RTSP session alive.

Otherwise I don't see a reason to make a tight binding between the 
transport connection and the RTSP session.

>
>> I don't know that having a feature tag for this will be useful. As 
>> far as I understand it neither side can really commit to having the 
>> connection open. Therefore it feels much more robust to assume that a 
>> client is free in its usage of persistent and non-persistent 
>> connections, and can at any point close a connection.
>
>
> I don't understand why neither side can commit to having the 
> connection open.  I think that if both sides agree to a persistent 
> connection, then defining rules for coupling of RTSP and RTP sessions 
> should be OK.
>
As I point out above a server can never trust its clients to never foul 
up. Therefore a mechanism must exist that allows the server to reclaim 
the resources dedicated to the client. This mechanism must give the 
client flexibility to in a simple fashion choose between persistent and 
non persistent connections.

Also we are not discussing coupling of a RTSP session  to RTP sessions, 
which are coupled after setup of media transport over RTP. What we are 
discussing is how the transport protocol transporting RTSP requests, 
especially TCP, relate to the RTSP session.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 06:13:25 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08213
	for ; Thu, 27 Jun 2002 06:13:25 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17724;
	Thu, 27 Jun 2002 06:06:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA17684
	for ; Thu, 27 Jun 2002 06:06:44 -0400 (EDT)
Received: from accord-ntsrv3.accord.co.il ([212.199.61.2])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08050;
	Thu, 27 Jun 2002 06:05:56 -0400 (EDT)
Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19)
	id ; Thu, 27 Jun 2002 13:06:08 +0300
Message-ID: 
From: "Even, Roni" 
To: "'Jonathan Rosenberg'" ,
        "Even, Roni"
	 
Cc: "'Joerg Ott'" ,
        "'mmusic@ietf.org'"
	 ,
        "'avt@ietf.org'" 
Subject: RE: [MMUSIC] FWD: I-D  ACTION:draft-even-mmusic-video-media-contr
	 ol-00.txt
Date: Thu, 27 Jun 2002 13:06:07 +0300
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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Jonathan,
The new picture request is used for two different thing.

1. The first one is tied to the freeze picture and is a preferred method to
change the source of the video so that there will not be artifacts. In
multipoint case the conference bridge when it wants to change the video seen
by the others, like in voice actitivated switching, sends a freeze request
to the recivers whose source is about to change and a new picture request to
the new source, the new full picture will release the recievers from their
freeze state. Now the question what is a change in the state of the session.
Is it a change of the codec or is it also a change in codec attribute, for
example a change from recvonly to send or picture orientation. I think that
a change of the stream source is like a change to send.

2. The other case is when a receiver loses synchronization and would like a
new picture in order to synchronize. This is not like a camera control or
device control. A new picture request applies to the media parameters as any
other media parameters to which we have attributes that affect the encoder
directly like ptime, orient, framerate, quality.
 
Thanks
Roni Even
> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Thursday, June 27, 2002 12:48 AM
> To: Even, Roni
> Cc: 'Joerg Ott'; 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D 
> ACTION:draft-even-mmusic-video-media-contr ol-00.txt
> 
> 
> inline.
> 
> Even, Roni wrote:
> > Hi Joerg,
> > Thanks for your comments.
> > 
> > 1. About the BNF I will fix it.
> > 
> > 2. I thought of having a section describing the usage in 
> SIP and SAP but
> > noticed that other drafts like offer/answer and simple 
> capabilities do
> > not
> > have section about SIP usage. If you meant that you want to 
> explain how
> > the
> > encoder uses this attribute to select the mode of operation 
> I can add
> > this
> > 
> > 3. About fast update and freeze. 
> > 	3.1 Using RTCP feedback for update was discussed in the last
> > meeting
> > and I agreed with the AVT guys that this should not be there
> > 	3.2 I would like to look at the new picture and freeze picture
> > in
> > the same context as a new codec request. This means that we use
> > signalling
> > to ask for a new codec and I see this feature as the same since I am
> > asking
> > for the same codec but with a new picture. If you want to look at it
> > from
> > the decoder wants a new codec or a new picture. Since 
> changing a codec
> > during a session is working in SAP and in SIP I do not see 
> the problem
> 
> THe problem is that the new picture request, in particular, is not a 
> change in STATE of the session, its a command to send a new 
> picture. The 
> SDP and offer/answer stuff is appropriate where there is a change in 
> state of the session parameters. That is not the case here. I also 
> suspect latency is an issue, since the video is distorted 
> until you get 
> the new intra picture. So it would seem to argue for a media 
> path thing. 
> Latency is generally not an issue for things like codec 
> change and hold.
> 
> The new picture request is a lot like things such as camera controls, 
> which are real-time media stream control activities. I am inclined to 
> argue that the appropriate solution is an e2e control protocol that, 
> like a media stream, is signaled in the SDP. We've argued 
> that the same 
> is true for thigns like floor control.
> 
> Freeze picture request does seem like its a lot like hold. Its a 
> persistent state of the session, and it must be explicitly changed to 
> get off of "freeze". Thus, I think an SDP approach here is fine.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 06:43:15 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09957
	for ; Thu, 27 Jun 2002 06:43:15 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20256;
	Thu, 27 Jun 2002 06:41:27 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20224
	for ; Thu, 27 Jun 2002 06:41:25 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09457;
	Thu, 27 Jun 2002 06:40:39 -0400 (EDT)
Message-Id: <200206271040.GAA09457@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mmusic@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 27 Jun 2002 06:40:39 -0400
Subject: [MMUSIC] I-D ACTION:draft-rojas-mmusic-qosreq-00.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for the QoS negotiation at the 
                          Application Layer
	Author(s)	: J. Rojas, S. Leroy, M. Holdrege
	Filename	: draft-rojas-mmusic-qosreq-00.txt
	Pages		: 11
	Date		: 26-Jun-02
	
This document identifies requirements for an end-to-end negotiation
of the Quality of Service (QoS) aspects of each media component of a
multi-media session at the application level, before requesting the
transport layer for bearer setup.
It is believed that in the future, QoS will be one of the major
differentiators in the context of a new generation of multi-media
services based on the IP technology. As such, QoS cannot be
considered anymore as a matter of bearer handling only, but it has
also to include the application layer. Moreover, QoS has to be
considered as part of the media component description, and
therefore, to be negotiated or re-negotiated during the session
life.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rojas-mmusic-qosreq-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rojas-mmusic-qosreq-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-rojas-mmusic-qosreq-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020626135026.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-rojas-mmusic-qosreq-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-rojas-mmusic-qosreq-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626135026.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 06:46:09 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10076
	for ; Thu, 27 Jun 2002 06:46:08 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20730;
	Thu, 27 Jun 2002 06:42:45 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA20699
	for ; Thu, 27 Jun 2002 06:42:43 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09793;
	Thu, 27 Jun 2002 06:41:57 -0400 (EDT)
Message-Id: <200206271041.GAA09793@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: mmusic@ietf.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Date: Thu, 27 Jun 2002 06:41:57 -0400
Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-05.txt
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

--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 SDP and RTSP
	Author(s)	: J. Arkko et al.
	Filename	: draft-ietf-mmusic-kmgmt-ext-05.txt
	Pages		: 12
	Date		: 26-Jun-02
	
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-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-kmgmt-ext-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20020626135257.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-05.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-mmusic-kmgmt-ext-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20020626135257.I-D@ietf.org>

--OtherAccess--

--NextPart--



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 12:31:26 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29565
	for ; Thu, 27 Jun 2002 12:31:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24162;
	Thu, 27 Jun 2002 12:30:31 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA24129
	for ; Thu, 27 Jun 2002 12:30:28 -0400 (EDT)
Received: from ns2.packetvideo.com (ns2.packetvideo.com [63.214.191.68])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29357
	for ; Thu, 27 Jun 2002 12:29:41 -0400 (EDT)
Received: from misty.packetvideo.com (pv-fw [63.214.191.66])
	by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id g5RGTta61759;
	Thu, 27 Jun 2002 09:29:55 -0700 (PDT)
Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19)
	id ; Thu, 27 Jun 2002 09:27:06 -0700
Message-ID: <72263E8E8622D611975C0002B32C19D84A720E@misty.packetvideo.com>
From: Thomas Zeng 
To: "'Magnus Westerlund'" 
Cc: mmusic@ietf.org
Subject: RE: [MMUSIC] RTSP: Connectionless vs. connection-based
Date: Thu, 27 Jun 2002 09:27:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
X-Filter-Version: 1.6a (ns2.packetvideo.com)
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Hi Magnus:

In the message below you suggest that  "the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic."

Later on you seem to imply that the onus is on the client to make sure 
that it sends a message (could be some keep alive message such as
OPTIONS) at least every 60 seconds (or according to RTSP  timeout interval).
(Or did you mean
the server is to ensure one message every 60 seconds? It was not clear to
me... hence this email...)

How about putting the onus on the server to ping the client when RTSP
session time-out
expires, and only kick out the client if no ping-response is receive after a
"RTSP response
timeout" (again a negotiable value, perhaps a few seconds)?

I say because I may have thin clients that I'd like to keep as simple as
possible. Servers on the other hand 
have more leeway. 

Regards,

thomas zeng,

packetvideo corp.
10350 Science Center Dr., Suite 210
San Diego, CA92121

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, June 27, 2002 12:21 AM
To: Jeremy Worley
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based


Hi Jeremy,

See my comments below.

Jeremy Worley wrote:

> Magnus, Jonathan,
>
> At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:
>
>>> It's probably worthwhile to allow either the client or the server to
>>> request a "persistent connection" on a session with a feature tag that
>>> tells the other end to not shut down.  This feature tag, in addition to
>>> what has been proposed before, could also enforce a 1:1
>>> session-connection binding for the session and connection in question.
>>> If the client sent it to the server, it would tell the server to make
>>> the session and connection timeouts the same, and to always shut down
>>> the session if the connection goes away.  It would also tell the client
>>> not to shut down the connection during the middle of the session.  The
>>> server should be able to ask this of the client independently of
>>> whether the client has asked it of the server.  The server might want
>>> to request this if a clustering system was in use where the client
>>> might be reconnected to a different server.  So it should be able to
>>> tell the client "if you hang up the connection, I am going to terminate
>>> your session.
>>
>
> I'm inclined to agree with Jonathan that a feature tag is desirable.  
> If a server can choose to terminate the RTSP session, forcing the 
> client to reconnect to send a message, then there are cases where the 
> cost of reconnect may be too high.  For example, a general purpose 
> RTSP server on the internet and a client on a high-latency network.  
> The server on the internet may be configured to not maintain 
> persistent sessions by default, assuming most sessions will be over 
> low latency links.  The client, being on a high latency network, would 
> prefer a persistent session. In this case, signalling a preference for 
> a persistent RTSP session could be beneficial.

>
> There may also be cases where the server would want to signal this.

Yes, I agree with the motivations you give above. However I don't see 
how a feature tag will help. The problem of when the server shall close 
the connection and recover the resources related to the connection still 
remains. If the client sends a feature tag saying it want to have a 
persistent connection and then the server receives no messages. When are 
the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, 
or never? To solve this problem I suggest that the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic. See text proposal for a section 9.3 in mmusic 
message:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.htm
l

If the server does not close unless a RTSP time-out time has passed the 
client has the choice to keep a persistent connection. It simply has to 
maintain it by sending a message normally at least every 60 seconds, 
these messages can also be used to keep the RTSP session alive.

Otherwise I don't see a reason to make a tight binding between the 
transport connection and the RTSP session.

>
>> I don't know that having a feature tag for this will be useful. As 
>> far as I understand it neither side can really commit to having the 
>> connection open. Therefore it feels much more robust to assume that a 
>> client is free in its usage of persistent and non-persistent 
>> connections, and can at any point close a connection.
>
>
> I don't understand why neither side can commit to having the 
> connection open.  I think that if both sides agree to a persistent 
> connection, then defining rules for coupling of RTSP and RTP sessions 
> should be OK.
>
As I point out above a server can never trust its clients to never foul 
up. Therefore a mechanism must exist that allows the server to reclaim 
the resources dedicated to the client. This mechanism must give the 
client flexibility to in a simple fashion choose between persistent and 
non persistent connections.

Also we are not discussing coupling of a RTSP session  to RTP sessions, 
which are coupled after setup of media transport over RTP. What we are 
discussing is how the transport protocol transporting RTSP requests, 
especially TCP, relate to the RTSP session.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Thu Jun 27 17:13:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16322
	for ; Thu, 27 Jun 2002 17:13:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24267;
	Thu, 27 Jun 2002 17:12:55 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19911
	for ; Thu, 27 Jun 2002 16:29:03 -0400 (EDT)
Received: from smtp.wanadoo.es (smtp5.wanadoo.es [62.37.236.139] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14221
	for ; Thu, 27 Jun 2002 16:28:16 -0400 (EDT)
Received: from risitas (62-37-137-222.dialup.uni2.es [62.37.137.222])
	by smtp.wanadoo.es (8.11.6/8.11.6) with ESMTP id g5S1LOs13375
	for ; Thu, 27 Jun 2002 21:21:24 -0400
Received: from fedemp by risitas with local (Exim 3.35 #1 (Debian))
	id 17Nfv3-00019r-00
	for ; Thu, 27 Jun 2002 22:31:09 +0200
Date: Thu, 27 Jun 2002 22:31:09 +0200
From: Federico Montesino Pouzols 
To: mmusic@ietf.org
Message-ID: <20020627203108.GA4407@risitas>
Reply-To: Federico Montesino Pouzols 
Mail-Followup-To: mmusic@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.25i
Subject: [MMUSIC] An error in SDP syntax regarding r= lines?
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

Hello everyone,

  On section 6 in draft-ietf-mmusic-sdp-new-10.txt the following
examples of r= lines are given:

# r=604800 3600 0 90000
# r=7d 1h 0 25h

  From this examples, I understand that "0" is a valid value for the
offsets. However on appendix A r= lines are defined like this:

# repeat-fields =       "r=" repeat-interval SP typed-time
#                      1*(SP typed-time)

# repeat-interval =     typed-time

# typed-time =          POS-DIGIT *DIGIT [fixed-len-time-unit]

# POS-DIGIT =           %x31-39 ; 1 - 9

  The two examples above would violate this syntax, since the first
offset is "0", which is not a POS-DIGIT. In RFC 2327, typed-time
started with DIGIT, so there was no problem.

  It seems to me, correct me please if I am wrong, that the first
offset, "0", is not necessary and could be assumed. Anyway, to keep
backward compatibility it has to be there. Would the following rule
solve the problem?

# repeat-fields =       "r=" repeat-interval SP typed-time SP "0"
#                      1*(SP typed-time)



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Fri Jun 28 00:13:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29526
	for ; Fri, 28 Jun 2002 00:13:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA15027;
	Fri, 28 Jun 2002 00:12:22 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA14992
	for ; Fri, 28 Jun 2002 00:12:20 -0400 (EDT)
Received: from neomagic.com (mailhost.neomagic.com [207.21.82.7])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29492
	for ; Fri, 28 Jun 2002 00:11:32 -0400 (EDT)
Received: from neomagic.com ([192.168.31.254])
	(authenticated)
	by neomagic.com (8.11.4/8.11.4) with ESMTP id g5S4AkX27025;
	Thu, 27 Jun 2002 21:10:47 -0700
Message-ID: <3D1C767E.4010205@neomagic.com>
Date: Fri, 28 Jun 2002 09:45:18 -0500
From: Vivek Mudgil 
Reply-To: vmudgil@neomagic.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Thomas Zeng , mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
References: <72263E8E8622D611975C0002B32C19D84A720E@misty.packetvideo.com>
Content-Type: multipart/alternative;
 boundary="------------030405090400000405010300"
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org


--------------030405090400000405010300
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

It has been an interesting reading this discussion on connectionless vs 
connection-based. Logically
it would make more sense if clients send the "I am alive" signal to the 
server. This philosophicaly is in line with the concept of load 
distribution.

Secondly I was just wondering why can't the "persistent connection" be 
made a default option for
RTSP connection with a time out on server side. This passes the onus of 
keeping the connection alive to the clients. Clients may have a 
configurable parameter which will allow the user to decide whether it 
wishes to work in persistent mode by periodically sending the 
"connection alive" signal or wishes to run in connectionless mode by 
closing the connection after each transaction. This is turn will be 
based on delay performance observed by the user in re-establishment of 
connection.

Regards

Vivek Mudgil

Thomas Zeng wrote:

>Hi Magnus:
>
>In the message below you suggest that  "the server shall not 
>close the a connection unless at least the RTSP session time-out  has 
>passed without traffic."
>
>Later on you seem to imply that the onus is on the client to make sure 
>that it sends a message (could be some keep alive message such as
>OPTIONS) at least every 60 seconds (or according to RTSP  timeout interval).
>(Or did you mean
>the server is to ensure one message every 60 seconds? It was not clear to
>me... hence this email...)
>
>How about putting the onus on the server to ping the client when RTSP
>session time-out
>expires, and only kick out the client if no ping-response is receive after a
>"RTSP response
>timeout" (again a negotiable value, perhaps a few seconds)?
>
>I say because I may have thin clients that I'd like to keep as simple as
>possible. Servers on the other hand 
>have more leeway. 
>
>Regards,
>
>thomas zeng,
>
>packetvideo corp.
>10350 Science Center Dr., Suite 210
>San Diego, CA92121
>
>-----Original Message-----
>From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
>Sent: Thursday, June 27, 2002 12:21 AM
>To: Jeremy Worley
>Cc: mmusic@ietf.org
>Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
>
>
>Hi Jeremy,
>
>See my comments below.
>
>Jeremy Worley wrote:
>
>  
>
>>Magnus, Jonathan,
>>
>>At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:
>>
>>    
>>
>>>>It's probably worthwhile to allow either the client or the server to
>>>>request a "persistent connection" on a session with a feature tag that
>>>>tells the other end to not shut down.  This feature tag, in addition to
>>>>what has been proposed before, could also enforce a 1:1
>>>>session-connection binding for the session and connection in question.
>>>>If the client sent it to the server, it would tell the server to make
>>>>the session and connection timeouts the same, and to always shut down
>>>>the session if the connection goes away.  It would also tell the client
>>>>not to shut down the connection during the middle of the session.  The
>>>>server should be able to ask this of the client independently of
>>>>whether the client has asked it of the server.  The server might want
>>>>to request this if a clustering system was in use where the client
>>>>might be reconnected to a different server.  So it should be able to
>>>>tell the client "if you hang up the connection, I am going to terminate
>>>>your session.
>>>>        
>>>>
>>I'm inclined to agree with Jonathan that a feature tag is desirable.  
>>If a server can choose to terminate the RTSP session, forcing the 
>>client to reconnect to send a message, then there are cases where the 
>>cost of reconnect may be too high.  For example, a general purpose 
>>RTSP server on the internet and a client on a high-latency network.  
>>The server on the internet may be configured to not maintain 
>>persistent sessions by default, assuming most sessions will be over 
>>low latency links.  The client, being on a high latency network, would 
>>prefer a persistent session. In this case, signalling a preference for 
>>a persistent RTSP session could be beneficial.
>>    
>>
>
>  
>
>>There may also be cases where the server would want to signal this.
>>    
>>
>
>Yes, I agree with the motivations you give above. However I don't see 
>how a feature tag will help. The problem of when the server shall close 
>the connection and recover the resources related to the connection still 
>remains. If the client sends a feature tag saying it want to have a 
>persistent connection and then the server receives no messages. When are 
>the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, 
>or never? To solve this problem I suggest that the server shall not 
>close the a connection unless at least the RTSP session time-out  has 
>passed without traffic. See text proposal for a section 9.3 in mmusic 
>message:
>http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.htm
>l
>
>If the server does not close unless a RTSP time-out time has passed the 
>client has the choice to keep a persistent connection. It simply has to 
>maintain it by sending a message normally at least every 60 seconds, 
>these messages can also be used to keep the RTSP session alive.
>
>Otherwise I don't see a reason to make a tight binding between the 
>transport connection and the RTSP session.
>
>  
>
>>>I don't know that having a feature tag for this will be useful. As 
>>>far as I understand it neither side can really commit to having the 
>>>connection open. Therefore it feels much more robust to assume that a 
>>>client is free in its usage of persistent and non-persistent 
>>>connections, and can at any point close a connection.
>>>      
>>>
>>I don't understand why neither side can commit to having the 
>>connection open.  I think that if both sides agree to a persistent 
>>connection, then defining rules for coupling of RTSP and RTP sessions 
>>should be OK.
>>
>>    
>>
>As I point out above a server can never trust its clients to never foul 
>up. Therefore a mechanism must exist that allows the server to reclaim 
>the resources dedicated to the client. This mechanism must give the 
>client flexibility to in a simple fashion choose between persistent and 
>non persistent connections.
>
>Also we are not discussing coupling of a RTSP session  to RTP sessions, 
>which are coupled after setup of media transport over RTP. What we are 
>discussing is how the transport protocol transporting RTSP requests, 
>especially TCP, relate to the RTSP session.
>
>Regards
>
>Magnus Westerlund 
>
>Multimedia Technologies, Ericsson Research ERA/TVA/A
>----------------------------------------------------------------------
>Ericsson AB                | Phone +46 8 4048287
>Torshamsgatan 23           | Fax   +46 8 7575550
>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se
>
>
>
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>_______________________________________________
>mmusic mailing list
>mmusic@ietf.org
>https://www1.ietf.org/mailman/listinfo/mmusic
>
>
>  
>


--------------030405090400000405010300
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


It has been an interesting reading this discussion on connectionless vs connection-based.
Logically

it would make more sense if clients send the "I am alive" signal to the server.
This philosophicaly is in line with the concept of load distribution. 



Secondly I was just wondering why can't the "persistent connection" be made
a default option for

RTSP connection with a time out on server side. This passes the onus of keeping
the connection alive to the clients. Clients may have a configurable parameter
which will allow the user to decide whether it wishes to work in persistent
mode by periodically sending the "connection alive" signal or wishes to run
in connectionless mode by closing the connection after each transaction.
This is turn will be based on delay performance observed by the user in re-establishment
of connection.



Regards



Vivek Mudgil



Thomas Zeng wrote:



  
Hi Magnus:

In the message below you suggest that  "the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic."

Later on you seem to imply that the onus is on the client to make sure 
that it sends a message (could be some keep alive message such as
OPTIONS) at least every 60 seconds (or according to RTSP  timeout interval).
(Or did you mean
the server is to ensure one message every 60 seconds? It was not clear to
me... hence this email...)

How about putting the onus on the server to ping the client when RTSP
session time-out
expires, and only kick out the client if no ping-response is receive after a
"RTSP response
timeout" (again a negotiable value, perhaps a few seconds)?

I say because I may have thin clients that I'd like to keep as simple as
possible. Servers on the other hand 
have more leeway. 

Regards,

thomas zeng,

packetvideo corp.
10350 Science Center Dr., Suite 210
San Diego, CA92121

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se]
Sent: Thursday, June 27, 2002 12:21 AM
To: Jeremy Worley
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based


Hi Jeremy,

See my comments below.

Jeremy Worley wrote:

  

  

    
Magnus, Jonathan,

At 01:28 PM 6/20/2002 +0200, Magnus Westerlund wrote:

    

    

      

        
It's probably worthwhile to allow either the client or the server to
request a "persistent connection" on a session with a feature tag that
tells the other end to not shut down.  This feature tag, in addition to
what has been proposed before, could also enforce a 1:1
session-connection binding for the session and connection in question.
If the client sent it to the server, it would tell the server to make
the session and connection timeouts the same, and to always shut down
the session if the connection goes away.  It would also tell the client
not to shut down the connection during the middle of the session.  The
server should be able to ask this of the client independently of
whether the client has asked it of the server.  The server might want
to request this if a clustering system was in use where the client
might be reconnected to a different server.  So it should be able to
tell the client "if you hang up the connection, I am going to terminate
your session.
        

      

    

    
I'm inclined to agree with Jonathan that a feature tag is desirable.  
If a server can choose to terminate the RTSP session, forcing the 
client to reconnect to send a message, then there are cases where the 
cost of reconnect may be too high.  For example, a general purpose 
RTSP server on the internet and a client on a high-latency network.  
The server on the internet may be configured to not maintain 
persistent sessions by default, assuming most sessions will be over 
low latency links.  The client, being on a high latency network, would 
prefer a persistent session. In this case, signalling a preference for 
a persistent RTSP session could be beneficial.
    

  

  

  

  

    
There may also be cases where the server would want to signal this.
    

  

  

Yes, I agree with the motivations you give above. However I don't see 
how a feature tag will help. The problem of when the server shall close 
the connection and recover the resources related to the connection still 
remains. If the client sends a feature tag saying it want to have a 
persistent connection and then the server receives no messages. When are 
the server going to close the connection, 1 min, 30 min, 1 hour, 1 day, 
or never? To solve this problem I suggest that the server shall not 
close the a connection unless at least the RTSP session time-out  has 
passed without traffic. See text proposal for a section 9.3 in mmusic 
message:
http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00681.htm
l

If the server does not close unless a RTSP time-out time has passed the 
client has the choice to keep a persistent connection. It simply has to 
maintain it by sending a message normally at least every 60 seconds, 
these messages can also be used to keep the RTSP session alive.

Otherwise I don't see a reason to make a tight binding between the 
transport connection and the RTSP session.

  

  

    

      
I don't know that having a feature tag for this will be useful. As 
far as I understand it neither side can really commit to having the 
connection open. Therefore it feels much more robust to assume that a 
client is free in its usage of persistent and non-persistent 
connections, and can at any point close a connection.
      

    

    
I don't understand why neither side can commit to having the 
connection open.  I think that if both sides agree to a persistent 
connection, then defining rules for coupling of RTSP and RTP sessions 
should be OK.

    

  

  
As I point out above a server can never trust its clients to never foul 
up. Therefore a mechanism must exist that allows the server to reclaim 
the resources dedicated to the client. This mechanism must give the 
client flexibility to in a simple fashion choose between persistent and 
non persistent connections.

Also we are not discussing coupling of a RTSP session  to RTP sessions, 
which are coupled after setup of media transport over RTP. What we are 
discussing is how the transport protocol transporting RTSP requests, 
especially TCP, relate to the RTSP session.

Regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


  








--------------030405090400000405010300--


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Fri Jun 28 03:05:27 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12613
	for ; Fri, 28 Jun 2002 03:05:27 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00530;
	Fri, 28 Jun 2002 03:03:41 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00497
	for ; Fri, 28 Jun 2002 03:03:40 -0400 (EDT)
Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12528
	for ; Fri, 28 Jun 2002 03:02:55 -0400 (EDT)
Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210])
	by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g5S73drU001767
	for ; Fri, 28 Jun 2002 09:03:39 +0200 (MEST)
Received: from era.ericsson.se
 (research-nnng7k.ki.sw.ericsson.se [147.214.34.108])
 by mbb1.ericsson.se (PMDF V5.2-29 #39352)
 with ESMTP id <0GYE00A2PMA2UO@mbb1.ericsson.se> for mmusic@ietf.org; Fri,
 28 Jun 2002 09:03:38 +0200 (MET DST)
Date: Fri, 28 Jun 2002 09:03:38 +0200
From: Magnus Westerlund 
Subject: Re: [MMUSIC] RTSP: Connectionless vs. connection-based
To: vmudgil@neomagic.com
Cc: Thomas Zeng , mmusic@ietf.org
Message-id: <3D1C0A4A.4080209@era.ericsson.se>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7bit
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4)
 Gecko/20011128 Netscape6/6.2.1
X-Accept-Language: en-us
References: <72263E8E8622D611975C0002B32C19D84A720E@misty.packetvideo.com>
 <3D1C767E.4010205@neomagic.com>
Content-Transfer-Encoding: 7bit
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

Hi Vivek and Thomas,

See my comments to both your mails inline.

Vivek Mudgil wrote:

> It has been an interesting reading this discussion on connectionless 
> vs connection-based. Logically
> it would make more sense if clients send the "I am alive" signal to 
> the server. This philosophically is in line with the concept of load 
> distribution.

Yes, I agree with you that it is a responsibility of the client to keep 
the connection alive. This would be in line with that it also is the 
clients responsibility to keep the RTSP session alive. However the 
server may of course try to ping the client before closing the 
connection. We can't mandate such a mechanism but it be a may or 
recommended. Also I do believe that  an options tag for this could be 
beneficial. That way the client will know how the server will behave.

>
> Secondly I was just wondering why can't the "persistent connection" be 
> made a default option for
> RTSP connection with a time out on server side. This passes the onus 
> of keeping the connection alive to the clients. Clients may have a 
> configurable parameter which will allow the user to decide whether it 
> wishes to work in persistent mode by periodically sending the 
> "connection alive" signal or wishes to run in connectionless mode by 
> closing the connection after each transaction. This is turn will be 
> based on delay performance observed by the user in re-establishment of 
> connection.
>
I don't want to make it default because that may result in loss of 
backwards compatibility towards non-persistent connections. To my 
understanding persistent connections is a special case of 
non-persistent. My goal is to write the specification so that makes no 
difference for the server to support both modes. The client has the 
choice to use what suits it. I do believe we are aiming for the same 
goal, let the client choose. 

> Thomas Zeng wrote:
>
>>Hi Magnus:
>>
>>In the message below you suggest that  "the server shall not 
>>close the a connection unless at least the RTSP session time-out  has 
>>passed without traffic."
>>
>>Later on you seem to imply that the onus is on the client to make sure 
>>that it sends a message (could be some keep alive message such as
>>OPTIONS) at least every 60 seconds (or according to RTSP  timeout interval).
>>(Or did you mean
>>the server is to ensure one message every 60 seconds? It was not clear to
>>me... hence this email...)
>>
It is the client that needs to send regular keep alive messages.

>>
>>How about putting the onus on the server to ping the client when RTSP
>>session time-out
>>expires, and only kick out the client if no ping-response is receive after a
>>"RTSP response
>>timeout" (again a negotiable value, perhaps a few seconds)?
>>
I can see the usefulness of this, but the default behavior must remain 
that it is the responsibility of the client. An options tag could be 
used by the server in a supported header to tell the client that it has 
this capability. Such a mechanism can be used for both the RTSP timeout 
and the connection timeout. Should both be included in the same tag or 
could they be separately implemented?

Thomas, could you draft a paragraph defining this for the connection to 
be included in the proposed section 9.3. I would like it to also define 
the options tag to use.

>>
>>I say because I may have thin clients that I'd like to keep as simple as
>>possible. Servers on the other hand 
>>have more leeway. 
>>

Implementing a keep alive mechanism is still required for the client. 
Otherwise it will lose the RTSP session, it can of course rely on RTCP. 
But if the code to implement a timer that sends regular connection and 
session keep alive is to much, I would recommend that this client use 
non-persistent connections. 

Best regards

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se




_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Fri Jun 28 09:43:54 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26190
	for ; Fri, 28 Jun 2002 09:43:54 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25875;
	Fri, 28 Jun 2002 09:41:28 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25782
	for ; Fri, 28 Jun 2002 09:38:00 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25840;
	Fri, 28 Jun 2002 09:37:14 -0400 (EDT)
Message-Id: <200206281337.JAA25840@ietf.org>
To: IETF-Announce: ;
Cc: mmusic@ietf.org
From: The IESG 
Reply-to: iesg@ietf.org
Date: Fri, 28 Jun 2002 09:37:13 -0400
Subject: [MMUSIC] Last Call: SDP: Session Description Protocol to Proposed
 Standard
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org


The IESG has received a request from the Multiparty Multimedia 
Session Control Working Group to consider SDP: Session Description 
Protocol  as a Proposed Standard.  

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the 
iesg@ietf.org or ietf@ietf.org mailing lists by July 12, 2002.

Files can be obtained via 
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-10.txt





_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Fri Jun 28 10:18:36 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27753
	for ; Fri, 28 Jun 2002 10:18:36 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28109;
	Fri, 28 Jun 2002 10:17:11 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27977
	for ; Fri, 28 Jun 2002 10:17:05 -0400 (EDT)
Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27525;
	Fri, 28 Jun 2002 10:16:18 -0400 (EDT)
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 KAA05278;
	Fri, 28 Jun 2002 10:16:27 -0400 (EDT)
Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221])
	by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20775;
	Fri, 28 Jun 2002 10:16:27 -0400 (EDT)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21)
	id ; Fri, 28 Jun 2002 10:16:26 -0400
Message-ID: <313680C9A886D511A06000204840E1CF030B55B6@whq-msgusr-02.pit.comms.marconi.com>
From: "Rosen, Brian" 
To: "'Jonathan Rosenberg'" ,
        "Even, Roni"
	 
Cc: "'Joerg Ott'" ,
        "'mmusic@ietf.org'"
	 ,
        "'avt@ietf.org'" 
Subject: RE: [MMUSIC] FWD: I-D  ACTION:draft-even-mmusic-video-media-contr
	 ol-00.txt
Date: Fri, 28 Jun 2002 10:16:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

We need to think carefully about this.
If you accept that we need a reasonably reliable communication
mechanism to accomplish tasks like video refresh, then we have,
it seems to me, three choices:

1. Use the signalling channel to do this.  Roni proposed 
a solution.
2. Create an entirely new protocol to do this.  
You proposed to do this.
3. Make RTCP reliable and use it.

I'm not thrilled about using the signalling channel, 
but it has the very large advantage that it's, by far, 
the simplest way to solve the problem.  What Roni proposes may 
be ugly to you, but it will work. Sure, there may be latency 
issues, but I suspect that it won't be a big deal.

Designing an entirely new media level protocol for 
command/response of course keeps us protocol designers with vast 
new opportunities to enjoy 'many fine lunches', and a purpose 
built protocol MAY be the most appropriate thing to do, but, 
realistically, how long would you estimate it could be done, 
and what do we do in the mean time?

Enhancing RTCP might be between these two approaches, 
but seems to warp the original purpose a fair amount.  
I'm not real sure it still isn't the wisest approach.  
Besides, it might make the acronym more appropriate :)

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Wednesday, June 26, 2002 5:48 PM
> To: Even, Roni
> Cc: 'Joerg Ott'; 'mmusic@ietf.org'; 'avt@ietf.org'
> Subject: Re: [MMUSIC] FWD: I-D
> ACTION:draft-even-mmusic-video-media-contr ol-00.txt
> 
> 
> inline.
> 
> Even, Roni wrote:
> > Hi Joerg,
> > Thanks for your comments.
> > 
> > 1. About the BNF I will fix it.
> > 
> > 2. I thought of having a section describing the usage in 
> SIP and SAP but
> > noticed that other drafts like offer/answer and simple 
> capabilities do
> > not
> > have section about SIP usage. If you meant that you want to 
> explain how
> > the
> > encoder uses this attribute to select the mode of operation 
> I can add
> > this
> > 
> > 3. About fast update and freeze. 
> > 	3.1 Using RTCP feedback for update was discussed in the last
> > meeting
> > and I agreed with the AVT guys that this should not be there
> > 	3.2 I would like to look at the new picture and freeze picture
> > in
> > the same context as a new codec request. This means that we use
> > signalling
> > to ask for a new codec and I see this feature as the same since I am
> > asking
> > for the same codec but with a new picture. If you want to look at it
> > from
> > the decoder wants a new codec or a new picture. Since 
> changing a codec
> > during a session is working in SAP and in SIP I do not see 
> the problem
> 
> THe problem is that the new picture request, in particular, is not a 
> change in STATE of the session, its a command to send a new 
> picture. The 
> SDP and offer/answer stuff is appropriate where there is a change in 
> state of the session parameters. That is not the case here. I also 
> suspect latency is an issue, since the video is distorted 
> until you get 
> the new intra picture. So it would seem to argue for a media 
> path thing. 
> Latency is generally not an issue for things like codec 
> change and hold.
> 
> The new picture request is a lot like things such as camera controls, 
> which are real-time media stream control activities. I am inclined to 
> argue that the appropriate solution is an e2e control protocol that, 
> like a media stream, is signaled in the SDP. We've argued 
> that the same 
> is true for thigns like floor control.
> 
> Freeze picture request does seem like its a lot like hold. Its a 
> persistent state of the session, and it must be explicitly changed to 
> get off of "freeze". Thus, I think an SDP approach here is fine.
> 
> -Jonathan R.
> 
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Fri Jun 28 12:44:53 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06126
	for ; Fri, 28 Jun 2002 12:44:53 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12867;
	Fri, 28 Jun 2002 12:43:51 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12815
	for ; Fri, 28 Jun 2002 12:43:48 -0400 (EDT)
Received: from david.siemens.de (david.siemens.de [192.35.17.14])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06006;
	Fri, 28 Jun 2002 12:43:00 -0400 (EDT)
Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14])
	by david.siemens.de (8.11.6/8.11.6) with ESMTP id g5SGhf426342;
	Fri, 28 Jun 2002 18:43:42 +0200 (MEST)
Received: from mail-y.mchp.siemens.de (mail-y.mchp.siemens.de [139.23.203.56])
	by mail1.siemens.de (8.11.6/8.11.6) with ESMTP id g5SGhdU19321;
	Fri, 28 Jun 2002 18:43:40 +0200 (MEST)
Received: from cs.columbia.edu ([139.21.148.221])
		by mail-y.mchp.siemens.de with ESMTP id g5SGhd3B019692;
		Fri, 28 Jun 2002 18:43:39 +0200 (MET DST)
Message-ID: <3D1C9211.6090206@cs.columbia.edu>
Date: Fri, 28 Jun 2002 12:42:57 -0400
From: Henning Schulzrinne 
Organization: Columbia University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Rosen, Brian" 
CC: "'Jonathan Rosenberg'" ,
        "Even, Roni"
 ,
        "'Joerg Ott'" ,
        "'mmusic@ietf.org'"
 ,
        "'avt@ietf.org'" 
Subject: Re: [AVT] RE: [MMUSIC] FWD: I-D  ACTION:draft-even-mmusic-video-media-contr
 ol-00.txt
References: <313680C9A886D511A06000204840E1CF030B55B6@whq-msgusr-02.pit.comms.marconi.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-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org
Content-Transfer-Encoding: 7bit

> 1. Use the signalling channel to do this.  Roni proposed 
> a solution.
> 2. Create an entirely new protocol to do this.  
> You proposed to do this.
> 3. Make RTCP reliable and use it.

There have been hints of this nature; see RFC 2032 for H.261.

> 
> I'm not thrilled about using the signalling channel, 
> but it has the very large advantage that it's, by far, 
> the simplest way to solve the problem.  What Roni proposes may 
> be ugly to you, but it will work. Sure, there may be latency 
> issues, but I suspect that it won't be a big deal.
> 
> Designing an entirely new media level protocol for 
> command/response of course keeps us protocol designers with vast 
> new opportunities to enjoy 'many fine lunches', and a purpose 
> built protocol MAY be the most appropriate thing to do, but, 
> realistically, how long would you estimate it could be done, 
> and what do we do in the mean time?

There's always RTSP that probably fits a bit better and avoids the proxy 
issues. (I'm not suggesting that this is the ideal solution, but it's 
another point in the design space.) It specifically has SET_PARAMETER 
for such purposes.

> 
> Enhancing RTCP might be between these two approaches, 
> but seems to warp the original purpose a fair amount.  
> I'm not real sure it still isn't the wisest approach.  
> Besides, it might make the acronym more appropriate :)

It would be tricky to do this right in the presence of RTP mixers and 
translators, to name just one set of problems.

> 
> Brian
> 


_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic


From mmusic-admin@ietf.org  Sun Jun 30 16:14:05 2002
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged))
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10422
	for ; Sun, 30 Jun 2002 16:14:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10343;
	Sun, 30 Jun 2002 16:08:21 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176])
	by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA10312
	for ; Sun, 30 Jun 2002 16:08:19 -0400 (EDT)
Received: from purple.nge.isi.edu (dial171.east.isi.edu [65.114.169.171])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10278
	for ; Sun, 30 Jun 2002 16:07:31 -0400 (EDT)
Received: from purple.nge.isi.edu (localhost [127.0.0.1])
	by purple.nge.isi.edu (8.12.4/8.12.4) with ESMTP id g5UIwPtD006165;
	Sun, 30 Jun 2002 14:58:25 -0400 (EDT)
	(envelope-from csp@purple.nge.isi.edu)
Message-Id: <200206301858.g5UIwPtD006165@purple.nge.isi.edu>
To: Federico Montesino Pouzols 
cc: mmusic@ietf.org
Subject: Re: [MMUSIC] An error in SDP syntax regarding r= lines? 
In-Reply-To: Your message of "Thu, 27 Jun 2002 22:31:09 +0200."
             <20020627203108.GA4407@risitas> 
Date: Sun, 30 Jun 2002 14:58:25 -0400
From: Colin Perkins 
Sender: mmusic-admin@ietf.org
Errors-To: mmusic-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Multiparty Multimedia Session Control Working Group 
X-BeenThere: mmusic@ietf.org

--> Federico Montesino Pouzols writes:
>Hello everyone,
>
>  On section 6 in draft-ietf-mmusic-sdp-new-10.txt the following
>examples of r= lines are given:
>
># r=604800 3600 0 90000
># r=7d 1h 0 25h
>
>  From this examples, I understand that "0" is a valid value for the
>offsets. However on appendix A r= lines are defined like this:
>
># repeat-fields =       "r=" repeat-interval SP typed-time
>#                      1*(SP typed-time)
>
># repeat-interval =     typed-time
>
># typed-time =          POS-DIGIT *DIGIT [fixed-len-time-unit]
>
># POS-DIGIT =           %x31-39 ; 1 - 9
>
>  The two examples above would violate this syntax, since the first
>offset is "0", which is not a POS-DIGIT. In RFC 2327, typed-time
>started with DIGIT, so there was no problem.
>
>  It seems to me, correct me please if I am wrong, that the first
>offset, "0", is not necessary and could be assumed. Anyway, to keep
>backward compatibility it has to be there. Would the following rule
>solve the problem?
>
># repeat-fields =       "r=" repeat-interval SP typed-time SP "0"
>#                      1*(SP typed-time)

I agree that it looks like a bug in the ABNF. A better fix might be to
change typed-time to be

	typed-time = 1*DIGIT [fixed-len-time-unit]

to avoid mandating a leading zero?

Colin

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic