From mailman-bounces@ietf.org Fri Oct 1 10:14:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02905 for ; Fri, 1 Oct 2004 10:14:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDOJv-000884-8U for mmusic-web-archive@ietf.org; Fri, 01 Oct 2004 10:23:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDKCp-0007CU-2A for mmusic-web-archive@ietf.org; Fri, 01 Oct 2004 06:00:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mmusic-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:23:07 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* 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%40ietf.org From mmusic-bounces@ietf.org Fri Oct 1 17:17:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22138 for ; Fri, 1 Oct 2004 17:17:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDUvN-0001Ov-Lj for mmusic-web-archive@ietf.org; Fri, 01 Oct 2004 17:26:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTmx-0007oq-KP; Fri, 01 Oct 2004 16:13:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDTQx-00030L-JT; Fri, 01 Oct 2004 15:51:15 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11141; Fri, 1 Oct 2004 15:51:14 -0400 (EDT) Message-Id: <200410011951.PAA11141@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 01 Oct 2004 15:51:13 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-connection-precon-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Connection-Establishment Preconditions in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo Filename : draft-ietf-mmusic-connection-precon-00.txt Pages : 8 Date : 2004-10-1 This document defines the connection-establishment precondition type for the SIP preconditions framework. Connection-establishment preconditions are met when a transport connection (e.g., a TCP connection) is successfully established between two endpoints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connection-precon-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-connection-precon-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-connection-precon-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: <2004-10-1153633.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-connection-precon-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-connection-precon-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-1153633.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Mon Oct 4 00:14:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27547 for ; Mon, 4 Oct 2004 00:14:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKOU-0004p4-6P for mmusic-web-archive@ietf.org; Mon, 04 Oct 2004 00:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuH-00030J-Cr; Sun, 03 Oct 2004 23:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJrj-0000Vy-GH for mmusic@megatron.ietf.org; Sun, 03 Oct 2004 23:50:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19551 for ; Sun, 3 Oct 2004 23:50:19 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE96g-00016u-H9 for mmusic@ietf.org; Sun, 03 Oct 2004 12:21:07 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60098 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE8x1-0003DC-Q9; Sun, 03 Oct 2004 17:11:07 +0100 In-Reply-To: <20040927105925.2514.qmail@web53702.mail.yahoo.com> References: <20040927105925.2514.qmail@web53702.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Re: draft-ietf-mmusic-sdp-new-20 Date: Sun, 3 Oct 2004 17:11:04 +0100 To: sunil bhargo X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit On 27 Sep 2004, at 11:59, sunil bhargo wrote: > in the following paragraph for the unicast IP > sessions :- > 1. In section 4.1 it is mentioned for unicast sessions > > "The semantics of this address and port depend on the > media and transport protocol defined. By default, > this SHOULD be the remote address and remote port to > which data is sent." > > but how can the sender identify which port the > receiver is ready to ready to receive the data on. An offer/answer exchange, or some similar means, outside the scope of SDP. > 2. also in section 5 it is mentioned that > > " An SDP session description consists of a > session-level section followed by zero or more > media-level sections. " > this implies that the m= line is OPTIONAL. > but then in the same section where the > differentiation of REQUIRED and OPTIONAL fields is > given > Media description > m= (media name and transport address) > m= does not contain the '*" field which means it is > essential but this contradicts the earlier statement. The "m=" line is mandatory if a media description is present, although the entire media description is optional. Would it clarify if the description before the list was changed to "OPTIONAL items in each section are marked with a *"? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 4 00:35:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25999 for ; Mon, 4 Oct 2004 00:12:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKMU-0003v5-RX for mmusic-web-archive@ietf.org; Mon, 04 Oct 2004 00:22:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJuA-0002tq-NT; Sun, 03 Oct 2004 23:52:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJrb-0000UZ-Gi for mmusic@megatron.ietf.org; Sun, 03 Oct 2004 23:50:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19430 for ; Sun, 3 Oct 2004 23:50:11 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE9BU-0005Dg-UV for mmusic@ietf.org; Sun, 03 Oct 2004 12:26:15 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60127 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE91q-0003LY-Nq; Sun, 03 Oct 2004 17:16:06 +0100 In-Reply-To: <20040927121842.84497.qmail@web53707.mail.yahoo.com> References: <20040927121842.84497.qmail@web53707.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <852F51E6-1557-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-20.txt Date: Sun, 3 Oct 2004 17:16:02 +0100 To: sunil bhargo X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Hi, On 27 Sep 2004, at 13:18, sunil bhargo wrote: > Doubts regarding the following sections :- > > 1. > "an SDP parser MUST completely ignore any session > description that contains a type letter that it does > not understand" > > Isn't the word MUST having very strong > implications which might not be necessary. For example > intermediate SDP parsers between the client and server > if everything that is not understood is rejected then > it might be problem. First thing that comes to mind > are the proxies(caching or dumb) they would have to > deny the service instead of proxying the presentation. True. > But somewhere else we mention as well > "An SDP parser MUST ignore any attribute it doesn't > understand." > So do we mean to say that any type other than > attribute if not understood then deny service or do we > mean something else. Correct. SDP is extended via attributes and it's likely that an attribute is not understood (and therefore ignored). New type letters are rarely if ever defined (none have been defined to date), so the correct response to them is to discard the session description. > 2. bwtype has missing RR and RS in section 5.8 or are > these intentionally missing. This is intentional, since they're defined elsewhere (in the referenced drafts). Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 4 00:35:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25240 for ; Mon, 4 Oct 2004 00:11:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKLV-0003RS-GQ for mmusic-web-archive@ietf.org; Mon, 04 Oct 2004 00:21:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJu9-0002sQ-BL; Sun, 03 Oct 2004 23:52:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEJrY-0000UC-MB for mmusic@megatron.ietf.org; Sun, 03 Oct 2004 23:50:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19390 for ; Sun, 3 Oct 2004 23:50:08 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE9FP-0007I7-EG for mmusic@ietf.org; Sun, 03 Oct 2004 12:30:08 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60155 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE95l-0003QT-0i; Sun, 03 Oct 2004 17:20:09 +0100 In-Reply-To: <20040929102504.92691.qmail@web53706.mail.yahoo.com> References: <20040929102504.92691.qmail@web53706.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <14B8F0F0-1558-11D9-B636-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-20.txt Date: Sun, 3 Oct 2004 17:20:03 +0100 To: sunil bhargo X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit I'm not sure I understand your question. For a layered encoding, "b=AS" would specify the bandwidth of the entire layered stream. Colin On 29 Sep 2004, at 11:25, sunil bhargo wrote: > Hi, > If the presentation is encoded into number of > streams(MBR) one expects to see equivalent number of > m= sections if that is so then how can multiple > streams refer to the same m= section as implied below > :- > > "For applications where hierarchically encoded > streams are being sent to a unicast address, it may be > necessary to specify multiple transport ports. This > is done using a similar notation to that used for IP > multicast addresses in the "c=" field: > m= / list> > In such a case, the ports used depend on the > transport protocol.For RTP, the default is that only > the even numbered ports are used for data with the > corresponding one-higher odd ports used for the RTCP > belonging to the RTP session, and the ports> > denoting the number of RTP sessions. For example: > m=video 49170/2 RTP/AVP 31 " > > If multiple streams don't refer to the same > section then / might not be > valid as each media section will give its own ports. > If multiple streams are mapped to one m= section then > how will the b=AS parameter be specified on per media > basis. But I might be missing something. > > sunil bhargo > > --- Colin Perkins wrote: > >> On 20 Sep 2004, at 20:42, Internet-Drafts@ietf.org >> wrote: >>> A New Internet-Draft is available from the on-line >> Internet-Drafts >>> directories. >>> This draft is a work item of the Multiparty >> Multimedia Session Control >>> Working Group of the IETF. >>> >>> Title : SDP: Session Description Protocol >>> Author(s) : M. Handley, et al. >>> Filename : draft-ietf-mmusic-sdp-new-20.txt >>> Pages : 45 >>> Date : 2004-9-20 >>> >>> This memo defines the Session Description Protocol >> (SDP). SDP is >>> intended for describing multimedia sessions for >> the purposes of >>> session announcement, session invitation, and >> other forms of >>> multimedia session initiation. >>> >>> A URL for this Internet-Draft is: >>> >> > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-20.txt >> >> There's a single change in this version: to remove >> the underspecified >> "control" and "data" media types, aligning the SDP >> media types with >> MIME media types. If there's a use for these media >> types they can be >> registered separately. They've been removed here in >> the interests of >> getting the base spec out. >> >> Colin >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 4 00:37:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03202 for ; Mon, 4 Oct 2004 00:37:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEKkR-0007Bo-I8 for mmusic-web-archive@ietf.org; Mon, 04 Oct 2004 00:46:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKNr-0004zM-NI; Mon, 04 Oct 2004 00:23:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEKEE-0005WA-JN for mmusic@megatron.ietf.org; Mon, 04 Oct 2004 00:13:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26565 for ; Mon, 4 Oct 2004 00:13:35 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CE2BX-00023Q-OK for mmusic@ietf.org; Sun, 03 Oct 2004 04:57:41 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60215 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CE21x-0001XI-B1; Sun, 03 Oct 2004 09:47:45 +0100 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Sun, 3 Oct 2004 09:47:37 +0100 To: mmusic ((E-mail)) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Joerg Ott Subject: [MMUSIC] Internet Draft deadlines for IETF 61 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit The deadlines for internet-draft submissions for the 61st IETF meeting in Washington DC are as follows: 11 October Pre-approval deadline for new working group drafts 18 October Submission deadline for new working group drafts 25 October Submission deadline for other drafts The deadline is at 9:00am US Eastern time on the date specified. Note the initial pre-approval deadline: if you are intending to submit a new working group draft (i.e. filename draft-ietf-mmusic-...-00.txt) you MUST contact the chairs to seek approval, in sufficient time that we can read the draft and send approval before 11th October. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 5 14:45:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24388 for ; Tue, 5 Oct 2004 14:45:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuSQ-0000Bl-47 for mmusic-web-archive@ietf.org; Tue, 05 Oct 2004 14:54:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEu6F-0006b4-17; Tue, 05 Oct 2004 14:31:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEu1X-0005rZ-Jf for mmusic@megatron.ietf.org; Tue, 05 Oct 2004 14:26:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22785 for ; Tue, 5 Oct 2004 14:26:54 -0400 (EDT) Received: from webmail.brixnet.com ([63.122.27.38] helo=brixcorp2.brixnet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEuAr-0005SG-MD for mmusic@ietf.org; Tue, 05 Oct 2004 14:36:34 -0400 Received: by mail.brixnet.com with Internet Mail Service (5.5.2657.72) id ; Tue, 5 Oct 2004 14:26:23 -0400 Message-ID: <07B0D4912B83D31188F300A0C9F62EBB03E7A67B@mail.brixnet.com> From: "Hedayat, Kaynam" To: "'mmusic@ietf.org'" Date: Tue, 5 Oct 2004 14:26:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [MMUSIC] New internet draft on media loopback X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d I would like to bring the attention of the group to a new internet draft on media loopback capability in SIP sessions. The draft can be found at http://www.ietf.org/internet-drafts/draft-hedayat-media-loopback-00.txt Regards, Kaynam ----------------------------------------- Kaynam Hedayat Chief Technology Officer Brix Networks 285 Mill Road Chelmsford, MA 01824 tel. 978.367.5611 fax. 978.367.5700 khedayat@brixnet.com www.brixnet.com See it before they hear it: Test the performance and quality of your VoIP at www.TestYourVoip.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 6 10:52:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03912 for ; Wed, 6 Oct 2004 10:52:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFDIz-0007vK-DI for mmusic-web-archive@ietf.org; Wed, 06 Oct 2004 11:02:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFD2V-0001c1-Kl; Wed, 06 Oct 2004 10:45:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFBVC-0002hf-T0 for mmusic@megatron.ietf.org; Wed, 06 Oct 2004 09:06:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21555 for ; Wed, 6 Oct 2004 09:06:41 -0400 (EDT) Received: from mailgate.uni-paderborn.de ([131.234.22.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFBeh-0000Zb-OQ for mmusic@ietf.org; Wed, 06 Oct 2004 09:16:32 -0400 Received: from feuerdorn.cs.upb.de ([131.234.64.26]) by mailgate.uni-paderborn.de with esmtp (TLSv1:AES256-SHA:256) (Exim 4.34) id 1CFBV8-0006xR-Oz for mmusic@ietf.org; Wed, 06 Oct 2004 15:06:38 +0200 Received: from fhkarl by feuerdorn.cs.upb.de with local (Exim 4.34) id 1CFBVA-0006at-BF for mmusic@ietf.org; Wed, 06 Oct 2004 15:06:40 +0200 To: mmusic@ietf.org Message-Id: From: Holger Karl Date: Wed, 06 Oct 2004 15:06:40 +0200 X-UNI-PB_FAK-EIM-MailScanner-Information: Please see http://imap.uni-paderborn.de for details X-UNI-PB_FAK-EIM-MailScanner: Found to be clean X-UNI-PB_FAK-EIM-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.011, required 4, LINES_OF_YELLING 0.01) X-MailScanner-From: fhkarl@feuerdorn.cs.upb.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f X-Mailman-Approved-At: Wed, 06 Oct 2004 10:45:09 -0400 Subject: [MMUSIC] Call for Papers: WiOpt '05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Dear Colleagues, Please note that the deadline for WiOpt'05 has been EXTENDED UNTIL October 10! The web site http://www.wiopt.org has full details. Our apologies for duplicate copies of this call. Best regards Holger Karl (on behalf of the Wiopt'05 organizers) ----------------------------------------------- The 3rd International Symposium on Modeling and Optimization in Mobile, Ad Hoc, and Wireless Networks (WiOpt'05) Riva del Garda, Trentino, Italy, April 3-7, 2005 http://www.wiopt.org SCOPE OF THE SYMPOSIUM ---------------------- The complexity of mobile, ad hoc, and wireless networks requires thoroughly founded models capturing their essential characteristics and new optimization techniques building upon such models. Insights into both the theoretical aspects of these problems as well as practical methods and tools are necessary. This symposium, building upon the two successful WiOpt workshops, intends to bring together researchers and practitioners working on optimization issues from different perspectives, including performance analysis, mobile networking, wireless communication, and optimization theory. Contributions to this conference should show new modeling and optimization techniques suitable for mobile/wireless networks or innovative applications of these techniques to improve network operation. Topics of interest include, but are not limited to: * Modeling techniques and tools for mobile/wireless networks * Performance characterisation & optimisation of mobile/wireless networks and systems * Mobile network optimisation: Applications, algorithms, and tools * Protocol design for optimal mobile network utilisation * Models and optimization approaches for energy efficiency, QoS, bandwidth economy and other aspects of mobile/wireless networks * Models and optimization techniques for non-standard network paradigms like sensor, vehicular, body area networks * Security and co-operation models for mobile networks * Pricing and incentives in mobile and ad-hoc networks Papers should be submitted as extended abstracts of up to 8 pages (see webpage for details). Selected papers from WiOpt 2005 will appear in a special issue of ACM/Kluwer Monet. ADJUNCT WORKSHOPS ----------------- Several one-day workshops will accompany the main WiOpt Symposium on April 3rd and 7th (see webpage for details): * WINMEE 2005: Measurement in Wireless Networks Chairs: L. Krishnamurthy (Intel), D. Papagiannaki (Intel Research Cambridge) * RAWNET 2005: Resource Allocation in Wireless Networks, Chairs: A. Proutiere (France Telecom R&D), S. Borst (Bell Labs.-CWI) * SPASWIN 2005: Stochastic Geometry for Wireless Networks, Chairs: F. Baccelli (INRIA-ENS), B. Blaszczyszyn (INRIA-ENS) * NETCOD 2005: Network Coding and Information Theory, Chairs: R. W. Yeung (The Chinese U. of Hong Kong), P. Chou (Microsoft Research) SPONSORHSIP ----------- WiOpt05 is sponsored by INRIA, Create-Net, ICST, eNext NoE, Intel, and Siemens mobile; it is technically co-sponsored by the IEEE Information Theory Society; it is organized in cooperation with ACM and IFIP WG 6.3. IMPORTANT DATES --------------- Submission deadline: Oct. 10, 2004 (midnight EST) Notification of acceptance: Dec. 5, 2004 Camera-ready copy: Jan. 5, 2005 Papers should be submitted in pdf or ps format through the EDAS system (http://edas.info). For more details, please visit http://www.wiopt.org General Chair ------------- E. Altman, INRIA Vice General Chair ------------------ H. Karl, U. of Paderbon Program Co-Chairs ----------------- R. R. Mazumdar, Purdue U. I. Stavrakakis, U. of Athens Steering Committee Chair ------------------------ I. Chlamtac, Create-Net Program Committee ----------------- E. Altman, INRIA V. Anantharam, UC Berkeley K. Avrachenkov, INRIA T. Basar, U. of Illinois A. Campbell, Columbia U. X. Cao, Hong Kong U. of Science and Technology A. Chockalingam, Indian Institute of Science M. Conti, CNR-ITT J. Crowcroft, U. of Cambridge P. Dube, IBM Research A. Ephremides, U. of Maryland S. Giordano, SUSPI A. Jukan, NSF CISE Networking Research H. Karl, U. of Paderborn P. Key, Microsoft Research J-W. Lee, Princeton U. R. Malhame, Ecole Poly-technique de Montreal P. Marbach, U. of Toronto D. Mcauley, Intel Research Cambridge A. Misra, IBM Research Q. Ni, National U. of Ireland Y. Onozato, Guma University A. Orda, Technion A. Panagakis, U. of Athens R. Rao, UC San Diego A. Richa, Arizona State U. P. Rodriguez, Microsoft Research C. Rosenberg, Purdue U. V. Syrotiuk, Aritona State U. T. Turletti, INRIA J. Wieselthier, Naval Research Laboratory M. Zukerman, U. of Melbourne Workshops Chair --------------- C. Barakat, INRIA Local Arrangements Chair ------------------------ G. Boata, U. of Trento Publicity Chair --------------- T. Turletti, INRIA Publications Chair ------------------ E. Deriche, INRIA _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 7 10:10:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18121 for ; Thu, 7 Oct 2004 10:10:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFZ8b-00079q-0Z for mmusic-web-archive@ietf.org; Thu, 07 Oct 2004 10:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYpe-0001Rh-0a; Thu, 07 Oct 2004 10:01:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYeK-00076g-2O for mmusic@megatron.ietf.org; Thu, 07 Oct 2004 09:49:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16293 for ; Thu, 7 Oct 2004 09:49:37 -0400 (EDT) Received: from smtp11.clb.oleane.net ([213.56.31.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYo1-0005qN-Qh for mmusic@ietf.org; Thu, 07 Oct 2004 09:59:42 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp11.clb.oleane.net with ESMTP id i97Dn7Vo017100 for ; Thu, 7 Oct 2004 15:49:07 +0200 Message-Id: <200410071349.i97Dn7Vo017100@smtp11.clb.oleane.net> From: "Peter" To: Date: Thu, 7 Oct 2004 15:49:02 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcSsdGdiJOBtzgMBT3a/84rt9OWtrQ== X-Spam-Score: 0.2 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [MMUSIC] WiMAX Summit: Call for proposal X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1706983665==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. --===============1706983665== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01C4AC85.2B4F4660" This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01C4AC85.2B4F4660 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . What is the business model for WiMAX? . What do we learn from earlier deployments? . What about the future extensions of the standard? . How is addressed the interoperability challenge? These questions, among others, will be addressed during the WiMAX Summit to be held in Paris next 5-8 April, 2005. A call for papers has been launched online, effective until October 29. Get all details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_00A4_01C4AC85.2B4F4660 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = What is the business model for WiMAX?
• = What do we learn from earlier deployments?
• = What about the future extensions of the standard?
• = How is addressed the interoperability challenge?

These questions, among others, will be addressed during the WiMAX Summit = to be held in Paris next 5-8 April, 2005.

A call for papers has = been launched online, effective until October = 29.

 

Get all details = at:

http://www.u= pperside.fr/wimax05/wimax2005intro.htm

 

 

------=_NextPart_000_00A4_01C4AC85.2B4F4660-- --===============1706983665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1706983665==-- From mmusic-bounces@ietf.org Sat Oct 9 17:03:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09681 for ; Sat, 9 Oct 2004 17:03:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGOXv-0005jM-OE for mmusic-web-archive@ietf.org; Sat, 09 Oct 2004 17:14:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGOKB-0002JT-DL; Sat, 09 Oct 2004 17:00:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGOHk-0001p7-Fr for mmusic@megatron.ietf.org; Sat, 09 Oct 2004 16:57:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09180 for ; Sat, 9 Oct 2004 16:57:46 -0400 (EDT) Received: from sundance.cse.ucsc.edu ([128.114.48.62]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CGORv-0005du-Fu for mmusic@ietf.org; Sat, 09 Oct 2004 17:08:20 -0400 Received: from localhost (ylwang@localhost) by sundance.cse.ucsc.edu (8.6.10/8.6.12) with ESMTP id NAA12638 for ; Sat, 9 Oct 2004 13:57:45 -0700 Date: Sat, 9 Oct 2004 13:57:45 -0700 (PDT) From: Yali Wang To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [MMUSIC] strange thing about attached text file (fwd) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 To Whom It May Concern: COuld you please help me? In my own screen, the text file of internet draft shows very neatly, at the top or the end of each page, I put the page remarking lines. But once after attached text file by email, then re-download and re-open it, it changes to messed-up lines, and looks very ugly. No matter how I modify the original,which in fact looks very good, as long as attached by email, then the the lines text file look ugly. Furthermore, I have the figure in the file. After attached, the figure always disppear. How should I solve this problem ? I used the Microsoft word 2000 for editing. Thanks. yali _______________________________________________ XCON mailing list XCON@ietf.org https://www1.ietf.org/mailman/listinfo/xcon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 11 06:16:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20373 for ; Mon, 11 Oct 2004 06:16:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxOP-0004Ce-5m for mmusic-web-archive@ietf.org; Mon, 11 Oct 2004 06:27:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGx90-0003U8-9K; Mon, 11 Oct 2004 06:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CGx8h-0003Jj-Lw for mmusic@megatron.ietf.org; Mon, 11 Oct 2004 06:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20090 for ; Mon, 11 Oct 2004 06:10:45 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CGxJD-00047q-G8 for mmusic@ietf.org; Mon, 11 Oct 2004 06:21:39 -0400 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:51083) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CGx8C-0006Zp-3m; Mon, 11 Oct 2004 11:10:16 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Internet Draft deadlines for IETF 61 Date: Mon, 11 Oct 2004 11:10:14 +0100 To: mmusic ((E-mail)) X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Joerg Ott X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Reminder: the internet-draft submission deadline for -00 drafts is one week from today. Colin On 3 Oct 2004, at 09:47, Colin Perkins wrote: > The deadlines for internet-draft submissions for the 61st IETF meeting > in Washington DC are as follows: > > 11 October Pre-approval deadline for new working group drafts > 18 October Submission deadline for new working group drafts > 25 October Submission deadline for other drafts > > The deadline is at 9:00am US Eastern time on the date specified. > > Note the initial pre-approval deadline: if you are intending to submit > a new working group draft (i.e. filename draft-ietf-mmusic-...-00.txt) > you MUST contact the chairs to seek approval, in sufficient time that > we can read the draft and send approval before 11th October. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 12 03:22:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24593 for ; Tue, 12 Oct 2004 03:22:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHHAW-0007Be-Jy for mmusic-web-archive@ietf.org; Tue, 12 Oct 2004 03:34:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGtK-0000DW-7d; Tue, 12 Oct 2004 03:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHGn2-0005xk-2X for mmusic@megatron.ietf.org; Tue, 12 Oct 2004 03:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24009 for ; Tue, 12 Oct 2004 03:09:42 -0400 (EDT) Received: from ipvpn069034.netvigator.com ([203.198.202.34] helo=asiwss01) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHGxe-0006yg-Ag for mmusic@ietf.org; Tue, 12 Oct 2004 03:20:46 -0400 Received: from ASPROEXG.astri.local ([10.6.2.21]) by asiwss01 with trend_isn t_name_B; Tue, 12 Oct 2004 15:12:45 +0800 Received: from asiayeah.com ([10.6.104.34]) by ASPROEXG.astri.local with Mic rosoft SMTPSVC(6.0.3790.0);Tue, 12 Oct 2004 15:09:45 +0800 Message-ID: <416B82D9.9070002@asiayeah.com> Date: Tue, 12 Oct 2004 15:08:09 +0800 From: Tony Yat-Tung Cheung User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Oct 2004 07:09:45.0390 (UTC) FILETIME=[73F704E0:01 C4B02A] X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:49.7994 C:20 M:1 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Some possible typos on draft-rosenberg-midcom-turn-05 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, We are looking at the TURN draft for implementation. We have found a few possible typos so far, 1) Page 6. "The TURN protocol will provide the STUN client with IP addresses that route to it from the public internet." We may replace "STUN client" with "TURN client". 2) Page 7 "Once a host sends packets to that transport address, it is ``locked down'', meaning that the client cannot cause packets to be sent to that host through the relay." This is rather hard to understand. Does that mean the following, "Once a peer sends packets to that transport address, it is "locked down", meaning that other peers cannot cause packets to be sent to that host through the relay." 3) Page 30: "TRANSPORT-PREFERENCES" "It is either 32 or 96 bits long". This is not true, because it contains a variable-size MAPPE-ADDRESS element. I think the size should be 32 bits or 32 bits + sizeof(MAPPED-ADDRESS). Thanks. Best Regards, Tony Cheung _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 12 14:40:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17887 for ; Tue, 12 Oct 2004 14:40:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRjt-0004Sd-D4 for mmusic-web-archive@ietf.org; Tue, 12 Oct 2004 14:51:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHRWJ-00075G-6f; Tue, 12 Oct 2004 14:37:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHRPC-0005TM-AC for mmusic@megatron.ietf.org; Tue, 12 Oct 2004 14:29:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17029 for ; Tue, 12 Oct 2004 14:29:49 -0400 (EDT) Received: from flawless.real.com ([207.188.23.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHRZz-0004Da-IU for mmusic@ietf.org; Tue, 12 Oct 2004 14:40:59 -0400 Received: from d845pebt2_xp.real.com ([::ffff:172.22.143.254]) (AUTH: LOGIN rmathew, SSL: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Tue, 12 Oct 2004 11:29:15 -0700 Message-Id: <6.1.2.0.2.20041012111619.0847a220@mailone.real.com> X-Sender: rmathew@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 12 Oct 2004 11:29:19 -0700 To: mmusic@ietf.org From: Rishi Mathew Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Transport Header Stipulation X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Magnus/All, This is regarding the Transport header defined in Chapter 14.43 of the RTSP spec. Right now, it says: The usage of any parameter that was not defined in RFC 2326 or in an extended way requires that request or response contains a Require header with the "play.basic" feature tag. It is claimed that this was done to prevent backwards compatibility problems. However, in our field implementation, this parameter has always had a different value than what was defined in the original RTSP spec. It looks like this: Transport: x-real-rdt/udp;client_port=6970;server_port=17738\r\n This was legal in the original spec. Obviously, any such stipulation is going to create more problems than it solves on the field. Our suggestion is that you remove this stipulation. Thanks, Rishi. Rishi Mathew Software Development Engineer Helix Development Support Group RealNetworks, Inc. rmathew@real.com 206.892.6126 http://www.helixcommunity.org http://www.realnetworks.com/products/support/devsupport.html _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 12 18:08:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20883 for ; Tue, 12 Oct 2004 18:08:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUz9-00052n-Rv for mmusic-web-archive@ietf.org; Tue, 12 Oct 2004 18:19:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUle-0001pp-Ah; Tue, 12 Oct 2004 18:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHUXu-0002Rq-BO for mmusic@megatron.ietf.org; Tue, 12 Oct 2004 17:51:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18669 for ; Tue, 12 Oct 2004 17:51:00 -0400 (EDT) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUij-0004d3-G0 for mmusic@ietf.org; Tue, 12 Oct 2004 18:02:13 -0400 Received: from [128.59.16.206] (chairpc.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id i9CLowuu019070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Oct 2004 17:50:59 -0400 (EDT) Message-ID: <416C51BD.9080608@cs.columbia.edu> Date: Tue, 12 Oct 2004 17:50:53 -0400 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.1.0, Antispam-Data: 2004.10.12.1 X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [MMUSIC] New draft on requirements for "Sharing and Remote Access to Applications" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Jonathan Lennox, Jason Nieh, Ricardo Baratto and I have put together an initial rough draft collecting requirements on sharing and remote access to applications. We believe that application sharing, as in some of the T.120 documents, and remote access to applications, exemplified in tools such as vnc, exhibit significant commonality. Until it appears in the archives, the draft can be found at http://www.cs.columbia.edu/sip/draft/sharing/draft-schulzrinne-mmusic-sharing-00.txt http://www.cs.columbia.edu/sip/draft/sharing/draft-schulzrinne-mmusic-sharing-00.html We would value comments and would like to request a slot at the MMUSIC meeting if there is group interest. Henning _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 14 07:16:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01608 for ; Thu, 14 Oct 2004 07:16:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI3m2-0007Sc-Tx for mmusic-web-archive@ietf.org; Thu, 14 Oct 2004 07:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3RF-0007Mx-P4; Thu, 14 Oct 2004 07:06:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CI3Q4-00076R-Bc for mmusic@megatron.ietf.org; Thu, 14 Oct 2004 07:05:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00772 for ; Thu, 14 Oct 2004 07:05:13 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CI3bC-0007G5-5b for mmusic@ietf.org; Thu, 14 Oct 2004 07:16:47 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9EB5CP6032640; Thu, 14 Oct 2004 13:05:12 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9EB5BBO032431; Thu, 14 Oct 2004 13:05:11 +0200 Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i9EB5B17012378; Thu, 14 Oct 2004 13:05:11 +0200 Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 14 Oct 2004 13:05:10 +0200 Message-ID: <8C878B55C96F924389908D4A7384842A03A02B49@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: "'mmusic@ietf.org'" , Euchner Martin Date: Thu, 14 Oct 2004 13:05:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: "'karl.norrman@ericsson.com'" , "'elisabetta.carrara@ericsson.com'" , "'mats.naslund@ericsson.com'" , "'fredrik.lindholm@ericsson.com'" , "'jari.arkko@ericsson.com'" Subject: [MMUSIC] re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 IANA Consideration section 8 of the draft allocates key management IDs (KMID) for the key management protocols. One KMID (not yet allocated by IANA) will be for MIKEY. Now here is my question: Assuming an example where the offerer advertises just 3 MIKEY protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK, Then the SDP would hold something like a=key-mgmt:mikey a1234a54... a=key-mgmt:mikey b454646ca54... a=key-mgmt:mikey c95785656ef3.... and the generated protocol list would be "mikey;mikey;mikey", where 'mikey' represents the allocated KMID value for the MIKEY protocol family. Q1) In the context of bidding-down protection, what kind of security does this list actually provide? I believe that an attacker could easily substitute another, weak 4th mikey key management protocol ("mikey-password") against one of the other three offered ones; yet the (MIKEY) protected protocol list would remain the same and the answer would not be able to detect the attack. My conclusion (needs confirmation) is that the design flaw is that the KMID is on a key management protocol family but it should rather be on the key management protocol option/varient. For MIKEY, the fix should be straightforward: Allocate a KMID for each of the MIKEY protocol variants; i.e. One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK. Cheers Martin. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 18 02:13:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13229 for ; Mon, 18 Oct 2004 02:13:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJQy5-0000a4-7U for mmusic-web-archive@ietf.org; Mon, 18 Oct 2004 02:26:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJQkk-0000yl-Au; Mon, 18 Oct 2004 02:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJQit-0000YF-33 for mmusic@megatron.ietf.org; Mon, 18 Oct 2004 02:10:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10454 for ; Mon, 18 Oct 2004 02:10:21 -0400 (EDT) Received: from mail2.cs.tut.fi ([130.230.4.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJQuo-0000Ud-ED for mmusic@ietf.org; Mon, 18 Oct 2004 02:22:42 -0400 Received: from samipelt (samipelt.atm.tut.fi [130.230.52.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.cs.tut.fi (Postfix) with ESMTP id 42FA0157931; Mon, 18 Oct 2004 09:09:49 +0300 (EEST) From: "Sami Peltotalo" To: "Mmusic" Date: Mon, 18 Oct 2004 09:11:19 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-walsh-mmusic-img-envelope-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Hi All, An update to Internet-Draft "The IMG Envelope" is now available. http://www.ietf.org/internet-drafts/draft-walsh-mmusic-img-envelope-00.txt All comments are very welcome. Regards, Sami Peltotalo. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 18 13:39:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05176 for ; Mon, 18 Oct 2004 13:39:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJbg8-0005IP-1Q for mmusic-web-archive@ietf.org; Mon, 18 Oct 2004 13:52:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJb1S-0000zt-Sk; Mon, 18 Oct 2004 13:10:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJagy-0005tl-Sb for mmusic@megatron.ietf.org; Mon, 18 Oct 2004 12:49:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23435 for ; Mon, 18 Oct 2004 10:54:40 -0400 (EDT) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJZ6J-0001z0-2g for mmusic@ietf.org; Mon, 18 Oct 2004 11:07:07 -0400 Received: from tzi.uni-bremen.de (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id i9IEsLYu010066; Mon, 18 Oct 2004 16:54:27 +0200 (MEST) Message-ID: <4173D91D.4050204@tzi.uni-bremen.de> Date: Mon, 18 Oct 2004 16:54:21 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Colin Perkins Subject: [MMUSIC] MMUSIC at 61st IETF X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Folks, MMUSIC is scheduled to meet once in Washington DC, currently on Tuesday, 9 Nov 2004, 9:00-11:30 This mail is to solicit input on the agenda. We have quite a few work items to finish up, so clear preference will be given to discuss and resolve issues with our deliverables. Please send requests for agenda time to the chairs (if you have not already done so) and please refer to the Internet Draft you will be discussing (and to issues to be discussed). Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 18 17:22:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24246 for ; Mon, 18 Oct 2004 17:22:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJf9B-0001pJ-J1 for mmusic-web-archive@ietf.org; Mon, 18 Oct 2004 17:34:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJeZQ-0001md-L4; Mon, 18 Oct 2004 16:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJTyV-0007lD-Ae for mmusic@megatron.ietf.org; Mon, 18 Oct 2004 05:38:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01959 for ; Mon, 18 Oct 2004 05:38:41 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJUAQ-0004Pr-2J for mmusic@ietf.org; Mon, 18 Oct 2004 05:51:05 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9I9ccRU005878 for ; Mon, 18 Oct 2004 11:38:38 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 18 Oct 2004 11:38:38 +0200 Received: from ericsson.com (research-64de67.ki.sw.ericsson.se [147.214.118.190]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J5PSFDB; Mon, 18 Oct 2004 11:38:32 +0200 Message-ID: <41738F1A.1090002@ericsson.com> Date: Mon, 18 Oct 2004 11:38:34 +0200 X-Sybari-Trust: 0f12f8ce 74898554 65bd7b3e 00000139 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Euchner Martin References: <8C878B55C96F924389908D4A7384842A03A02B49@mchh2c7e.mchh.siemens.de> In-Reply-To: <8C878B55C96F924389908D4A7384842A03A02B49@mchh2c7e.mchh.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Oct 2004 09:38:38.0431 (UTC) FILETIME=[3EF366F0:01C4B4F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 18 Oct 2004 16:57:30 -0400 Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , "Fredrik Lindholm \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Hi Martin, Thanks for raising this issue. It is known to us and was discussed internally when deciding for the current protection mechanism. Perhaps we should have motivated why we did not consider this a threat to be taken care of, but now that you raise the issue, let's see if we can settle it. Euchner Martin wrote: > IANA Consideration section 8 of the draft allocates key management IDs (KMID) for the key management protocols. One KMID (not yet allocated by IANA) will be for MIKEY. > > Now here is my question: > > Assuming an example where the offerer advertises just 3 MIKEY protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK, > > Then the SDP would hold something like > a=key-mgmt:mikey a1234a54... > a=key-mgmt:mikey b454646ca54... > a=key-mgmt:mikey c95785656ef3.... First of all, why would this be something that ever occurs? The reason we allow several options is to let the parties agree on a particular prefered *protocol*, but choosing options within one and the same protocol is not intended to be done at this level. (Anyway, let's assume it can happen...) > > and the generated protocol list would be "mikey;mikey;mikey", where 'mikey' represents the allocated KMID value for the MIKEY protocol family. Right. > > Q1) In the context of bidding-down protection, what kind of security does this list actually provide? > > I believe that an attacker could easily substitute another, weak 4th mikey key management protocol ("mikey-password") against one of the other three offered ones; yet the (MIKEY) protected protocol list would remain the same and the answer would not be able to detect the attack. Okay, let's assume he can. To accomplish this, the "mikey-password" variant needs to be so weak that he can fake the authentiction data of the a-line where this is inserted. That is, the authentication mechanism of the password variant is completely insecure. But if this is so, the attacker does not even need the "real" Initiator to be on-line: he can at any point in time impersonate the real Initiator, faking MIKEY messages using the password variant. Therefore... > > My conclusion (needs confirmation) is that the design flaw is that the KMID is on a key management protocol family but it should rather be on the key management protocol option/varient. > > For MIKEY, the fix should be straightforward: Allocate a KMID for each of the MIKEY protocol variants; i.e. > One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK. ...this protection mechanism is totally inadequate for the case you describe, the "real" security hole remains open even if we were to add this feature. Another scenario in which the suggested protection is not enough is as follows: suppose preshared-MIKEY is extended by a cipher/MAC combination which has poor security. It may then not be enough to authenticate the fact MIKEY-preshared was offered, but rather the exact options at the transform level (which *is* done in each a-line individually, but not across a-lines). However, we would exclude this as a threat for the same reason as above: if faked MIKEY lines can be inserted by an attacker, the problem is not of bidding-down nature, it is really a fundamental security flaw of the protocol as such. Finally, if one is still concerned by this, we would suggest that the Initiator uses MIKEY's option of requesting a verification message back from the Responder. If an attacker modifies the offer to contain something the Initiator actually didn't offer, the response back will be generated by an incorrect method/key, and the Initiator will detect this when checking the response. Best, /Mats and MIKEY gang _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 05:51:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06152 for ; Tue, 19 Oct 2004 05:51:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqqg-0000Qi-5z for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 06:04:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqOX-0000tN-TG; Tue, 19 Oct 2004 05:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJpxY-0005OY-CT for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 05:07:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03291 for ; Tue, 19 Oct 2004 05:07:05 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJq9c-0007ye-Np for mmusic@ietf.org; Tue, 19 Oct 2004 05:19:42 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9J974RU025212 for ; Tue, 19 Oct 2004 11:07:04 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 11:07:04 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J526GA3; Tue, 19 Oct 2004 11:07:02 +0200 Message-ID: <4174D936.2080109@ericsson.com> Date: Tue, 19 Oct 2004 11:07:02 +0200 X-Sybari-Trust: d41b77d6 bfd556f1 986d9f48 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Rishi Mathew Subject: Re: [MMUSIC] Transport Header Stipulation References: <6.1.2.0.2.20041012111619.0847a220@mailone.real.com> In-Reply-To: <6.1.2.0.2.20041012111619.0847a220@mailone.real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2004 09:07:04.0510 (UTC) FILETIME=[007FBDE0:01C4B5BB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Hi Mathew See below Rishi Mathew wrote: > Magnus/All, > > This is regarding the Transport header defined in Chapter 14.43 of the > RTSP spec. Right now, it says: > > The usage of any parameter that was not defined in RFC 2326 or in an > extended way requires that request or response contains a Require > header with the "play.basic" feature tag. > What I refer to as parameter is the addition of what in the ABNF is called parameter, i.e. what comes after the protocol specifier. For example a new parameter would be the "new_parm" below: Transport: x-real-rdt/udp;client_port=6970;server_port=17738; new_parm=XYZ > It is claimed that this was done to prevent backwards compatibility > problems. However, in our field implementation, this parameter has > always had a different value than what was defined in the original RTSP > spec. It looks like this: > > Transport: x-real-rdt/udp;client_port=6970;server_port=17738\r\n > > This was legal in the original spec. Obviously, any such stipulation is > going to create more problems than it solves on the field. Our > suggestion is that you remove this stipulation. > "x-real-rdt/udp" is protocol specifier. However that you claim that it is legal in RFC 2326 is not correct. The ABNF for the transport header looks like this: Transport = "Transport" ":" 1\#transport-spec transport-spec = transport-protocol/profile[/lower-transport] *parameter transport-protocol = "RTP" profile = "AVP" lower-transport = "TCP" | "UDP" Which means that no extension allowance was made in the ABNF. Thus it is unclear that a parser will correctly handle any extension. I do agree that the intention was to allow for this. However due to the shortcoming of the RFC 2326 it is a dangerous proposition to use extension protocol specifiers or parameters. That is the reason the text is present in the draft. If you compare the above ABNF with the new one present in the draft: Transport = "Transport" ":" transport-spec *("," LWS transport-spec) transport-spec = transport-id *parameter transport-id = transport-prot "/" profile ["/" lower-transport] ; no LWS is allowed inside transport-id transport-prot = "RTP" / token profile = "AVP" / token lower-transport = "TCP" / "UDP" / token You see that there now is specified that all these types can be extended. The draft do also define IANA registries for these points of extension, see 20.5. So I don't think it is appropriate to remove this, as it can't be guaranteed that your proprietary extensions would correctly work with another implementation following RFC 2326. When clients support the updated specification and indicates this correctly, then you can be certain that any correct implementation can safely ignore your proprietary transport protocol. So I think I will need to clarify the note to apply to any extensions. I also should change the wording to not use the word "require". My proposed change is: "The usage of any parameter or protocol specifier not defined in RFC 2326 or which is extended, SHALL be indicated by the use of the Require header and a feature tag(s) to ensure support by the receiver. This is to protect against failures with uncertain consequences, as the a receiver of a message may do anything between ignoring a parameter, to complete refuse the message." Any Comments? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 06:14:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07573 for ; Tue, 19 Oct 2004 06:14:48 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJrCw-0000oI-IV for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 06:27:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJqTc-0001xX-PJ; Tue, 19 Oct 2004 05:40:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJq5G-0006xr-QN for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 05:15:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03873 for ; Tue, 19 Oct 2004 05:15:03 -0400 (EDT) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJqH6-00089z-CY for mmusic@ietf.org; Tue, 19 Oct 2004 05:27:40 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9J9EmRU028157 for ; Tue, 19 Oct 2004 11:14:48 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 11:14:48 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J52625P; Tue, 19 Oct 2004 11:14:46 +0200 Message-ID: <4174DB06.40702@ericsson.com> Date: Tue, 19 Oct 2004 11:14:46 +0200 X-Sybari-Trust: f3235107 bfd556f1 986d9f48 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: Colin Perkins References: <200409201942.PAA05336@ietf.org> <6191FD82-0B51-11D9-9902-000A957FC5F2@csperkins.org> In-Reply-To: <6191FD82-0B51-11D9-9902-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2004 09:14:48.0278 (UTC) FILETIME=[14ED1F60:01C4B5BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: "mmusic \(\(E-mail\)\)" Subject: [MMUSIC] Change proposal for draft-ietf-mmusic-sdp-new-20.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Hi Colin, In the work on updating RFC 3267 (AMR and AMR-WB RTP payload format) which originally defines "a=maxptime" I have recieved a request for clarification that I think make sense and which do not create any backwards compatibility issues: In Section 6: under attribue "a=maxptime:" I would like to rephrase the sentence: "The time SHOULD be a multiple of the frame size." To: "The time SHOULD be an integer multiple of the frame size. ^^^^^^^^^ Comments? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 08:04:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15320 for ; Tue, 19 Oct 2004 08:04:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJsut-0002rT-8R for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 08:16:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJsIu-0002BW-Cf; Tue, 19 Oct 2004 07:37:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJryY-0007sn-26 for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 07:16:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11826 for ; Tue, 19 Oct 2004 07:16:14 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJsAe-0001ul-HW for mmusic@ietf.org; Tue, 19 Oct 2004 07:28:53 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9JBGFWR021417 for ; Tue, 19 Oct 2004 13:16:15 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 19 Oct 2004 13:16:15 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4J527R8Z; Tue, 19 Oct 2004 13:16:15 +0200 Message-ID: <4174F77E.70807@ericsson.com> Date: Tue, 19 Oct 2004 13:16:14 +0200 X-Sybari-Trust: f33c9b0f bfd556f1 986d9f48 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? References: <20040824111640.1982.qmail@web40603.mail.yahoo.com> In-Reply-To: <20040824111640.1982.qmail@web40603.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2004 11:16:15.0189 (UTC) FILETIME=[0C438050:01C4B5CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi, Lets revive this issue so that I can edit in the resolution if possible. I had proposed that we consider either of the solutions: > 1. Define a separate proxy-supported header, similar to the > proxy-require header. This header would then be populated by the > requester with all proxy-related feature tags that it supports. Then the > proxy would simply forward the header with the common set of tags it > support. The server simply echoes the header in the response. The > proxies should ignore the header in the response messages. > > 2. Allow the server to modify the supported headers to only contain > functionality it also supports. Sunil Bhargo: > Therefore i am ok with the suggestion number 2 > that you have mentioned. Please let me know your > suggestions. When I looked at this now, I think we have a serious problem with proposal number 2. The problem is that the proxy chain can remove feature tags that are applicable only to servers. This is not good as the proxies could prevent the client or server from learning about a feature that the proxy will simply do pass-through on. The only solution that I currently can think of for this problem would be to prefix the feature tags with its type; proxy, server or both. However that may be problematic to deploy. I would also like to respond to some of Sunil's comments: > We also need to take into consideration that the > client sometime might not be aware of the existence of > the proxy. This can be in the cases of transparency or > accelerated proxy deployment. In such cases even if we > add the proxy-Supported header the client is not going > to send it but will send the Supported header. I don't think this is a real issue, if a proxy sees a Supported header but no Proxy-Supported, the first proxy in the chain simply adds it. It is after all also the proxy that needs to learn if it can support any functionality that the session may consider. Also I think that we in this specification can simply request that any updates client simply always add the proxy-supported header, if it intends to use supported. > Also one problem in having a separate header > proxy-supported and Supported is that even if the > client receives both the proxy-supported and supported > header in the response it should use the common set of > features in both the proxy-supported and nsupported > headers and this can be acheived by only having the > supported header. Yes, I agree that one needs to consider what the common set is. However that is the issue for the requester, that desires to use a feature. If that feature is supported by the requester it needs to understand it, and will also be able to determine which server and/or proxy features that needs to be supported to make the desired feature work. Thus I think it much easier for the requesting peer to make that combination than for an entity in the middle to do it. Having two headers also allows for a nice separation of any feature tag depending on its type. Server only features goes in supported, proxy only goes in proxy-supported and feature for both domains goes in both. This also gives a client that are capable of bypassing proxies to do it if required to get a certain feature that are not supported by the proxy chain. Please comment! Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 23:02:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20257 for ; Tue, 19 Oct 2004 23:02:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6wn-0004U7-1j for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 23:15:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fU-0007Da-VC; Tue, 19 Oct 2004 20:49:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyYg-00058A-So for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 14:18:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25256 for ; Tue, 19 Oct 2004 14:18:00 -0400 (EDT) Received: from web53707.mail.yahoo.com ([206.190.37.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CJykp-0005ia-Tt for mmusic@ietf.org; Tue, 19 Oct 2004 14:30:41 -0400 Message-ID: <20041019181728.73664.qmail@web53707.mail.yahoo.com> Received: from [202.4.189.74] by web53707.mail.yahoo.com via HTTP; Tue, 19 Oct 2004 11:17:28 PDT Date: Tue, 19 Oct 2004 11:17:28 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? To: Magnus Westerlund In-Reply-To: <4174F77E.70807@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Hi Magnus, Thanks for the reply. I agree to your concerns regarding the option 2 of not modifying the Supported header by the intervening proxy or server. I am ok with option 1. In case of proxy chain then the client will receive the common set of features in the proxy-supported header. But what is the solution about clients supporting the previous versions ,that is only the supported header. In that case i think the proxy should be allowed to write the supported headers. Just wanted add one thing that the user/player should never make the bypassing decision based on the Supported headers feature-tags as inclusion of any feature-tag in Supported header should be optional session feature and the player/client should be able to live with/without this feature tag. If something is mandatory then it should be included into require and proxy-require headers. Can we add the text that the client is advised to use only the common set of features in proxy-supported and supported headers ? sunil bhargo --- Magnus Westerlund wrote: > Hi, > > Lets revive this issue so that I can edit in the > resolution if possible. > > I had proposed that we consider either of the > solutions: > > > 1. Define a separate proxy-supported header, > similar to the > > proxy-require header. This header would then be > populated by the > > requester with all proxy-related feature tags that > it supports. Then the > > proxy would simply forward the header with the > common set of tags it > > support. The server simply echoes the header in > the response. The > > proxies should ignore the header in the response > messages. > > > > 2. Allow the server to modify the supported > headers to only contain > > functionality it also supports. > > Sunil Bhargo: > > Therefore i am ok with the suggestion number > 2 > > that you have mentioned. Please let me know your > > suggestions. > > When I looked at this now, I think we have a serious > problem with > proposal number 2. The problem is that the proxy > chain can remove > feature tags that are applicable only to servers. > This is not good as > the proxies could prevent the client or server from > learning about a > feature that the proxy will simply do pass-through > on. > > The only solution that I currently can think of for > this problem would > be to prefix the feature tags with its type; proxy, > server or both. > However that may be problematic to deploy. > > I would also like to respond to some of Sunil's > comments: > > We also need to take into consideration that > the > > client sometime might not be aware of the > existence of > > the proxy. This can be in the cases of > transparency or > > accelerated proxy deployment. In such cases even > if we > > add the proxy-Supported header the client is not > going > > to send it but will send the Supported header. > > I don't think this is a real issue, if a proxy sees > a Supported header > but no Proxy-Supported, the first proxy in the chain > simply adds it. It > is after all also the proxy that needs to learn if > it can support any > functionality that the session may consider. Also I > think that we in > this specification can simply request that any > updates client simply > always add the proxy-supported header, if it intends > to use supported. > > > > Also one problem in having a separate header > > proxy-supported and Supported is that even if the > > client receives both the proxy-supported and > supported > > header in the response it should use the common > set of > > features in both the proxy-supported and > nsupported > > headers and this can be acheived by only having > the > > supported header. > > Yes, I agree that one needs to consider what the > common set is. However > that is the issue for the requester, that desires to > use a feature. If > that feature is supported by the requester it needs > to understand it, > and will also be able to determine which server > and/or proxy features > that needs to be supported to make the desired > feature work. Thus I > think it much easier for the requesting peer to make > that combination > than for an entity in the middle to do it. > > Having two headers also allows for a nice separation > of any feature tag > depending on its type. Server only features goes in > supported, proxy > only goes in proxy-supported and feature for both > domains goes in both. > > This also gives a client that are capable of > bypassing proxies to do it > if required to get a certain feature that are not > supported by the proxy > chain. > > Please comment! > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 23:04:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20324 for ; Tue, 19 Oct 2004 23:04:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6yZ-0004VZ-AU for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 23:17:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fW-0007GS-JJ; Tue, 19 Oct 2004 20:49:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJyZx-0005Af-WE for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 14:19:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25326 for ; Tue, 19 Oct 2004 14:19:16 -0400 (EDT) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJym4-0005lP-H0 for mmusic@ietf.org; Tue, 19 Oct 2004 14:31:57 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id i9JIJDP6031085; Tue, 19 Oct 2004 20:19:13 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i9JIJDYO022574; Tue, 19 Oct 2004 20:19:13 +0200 Received: from mchh246e.mchh.siemens.de (mchh246e.mchh.siemens.de [139.21.200.56]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i9JIJC17001634; Tue, 19 Oct 2004 20:19:12 +0200 Received: by mchh246e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id <4739ZRNN>; Tue, 19 Oct 2004 20:19:12 +0200 Message-ID: <8C878B55C96F924389908D4A7384842A03A02B85@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: =?iso-8859-1?Q?=27Mats_N=E4slund=27?= , Euchner Martin Date: Tue, 19 Oct 2004 20:19:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: quoted-printable Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , "Fredrik Lindholm \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] RE: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable Mats, Many thanks to you and the entire MIKEY crew for answering my question. On one hand, I understand your response (see my acknowledgement below), = one the other hand put some further comments for discussion and yet in = some other areas I believe that there may be just a resolvable = misunderstanding. I'm addressing the issues inline below. Cheers Martin -----Original Message----- From: Mats N=E4slund [mailto:mats.naslund@ericsson.com]=20 Sent: Montag, 18. Oktober 2004 11:39 To: Euchner Martin Cc: mmusic@ietf.org; Jari Arkko (JO/LMF); Elisabetta Carrara (KI/EAB); = Fredrik Lindholm (KI/EAB); Karl Norrman (KI/EAB) Subject: Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA = considerations section > > Assuming an example where the offerer advertises just 3 MIKEY=20 protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK, > > Then the SDP would hold something like > a=3Dkey-mgmt:mikey a1234a54... > a=3Dkey-mgmt:mikey b454646ca54... > a=3Dkey-mgmt:mikey c95785656ef3.... First of all, why would this be something that ever occurs? The reason we allow several options is to let the parties agree on a particular prefered *protocol*, but choosing options within one and the same protocol is not intended to be done at this level. MEU:> Ok this confirms that kmtext "negotiates" a key management = protocol family, but does not actually negotiate any particular key = management capability. I intentionally put negotiate in quotes, since = this SDP-based negotiation is operating just on the family - level of = the key management protocol but certainly not on protocol capabilities = (such as a particular choice like MIKEY-PK, or even more fine grained = on a crypto algorithm level). So in order to "negotiate" any deeper = than the family-level, kmgtext offers the desired MIKEY protocol = variants in parallel. Unfortunately, this increases the processing time = of the offerer considerably; namely 3 times to instantiate and to = compile 3 different MIKEY key management protocol messages. For the = answerer, the work load is not as high as on the offerer, but still the = base64 decoding requires some more effort than just a quick inspection = of a specific KMID would cost; so this latter point is really a minor = issue. I should clearly say, that I don't see any better alternative for a = full 2-way handshake negotiation process yet a 4-way handshake would = not face the parallel explosion property. (Anyway, let's assume it can happen...) > > and the generated protocol list would be "mikey;mikey;mikey", where=20 'mikey' represents the allocated KMID value for the MIKEY protocol = family. Right. > > Q1) In the context of bidding-down protection, what kind of security = does this list actually provide? > > I believe that an attacker could easily substitute another, weak 4th = mikey key management protocol ("mikey-password") against one of the=20 other three offered ones; yet the (MIKEY) protected protocol list would = remain the same and the answer would not be able to detect the attack. Okay, let's assume he can. To accomplish this, the "mikey-password" variant needs to be so weak that he can fake the authentiction data of the a-line where this is inserted. That is, the authentication = mechanism of the password variant is completely insecure. But if this is so, the attacker does not even need the "real" Initiator to be on-line: he can at any point in time impersonate the real Initiator, faking MIKEY messages using the password variant. Therefore... MEU:> Here I sense a minor misunderstanding. I'm clearly not = questioning the security of any MIKEY protocol nor am I saying that any = MIKEY protocol is any close to being weak that it could be broken. My only concern in the context of a bidding-down attack is, that the = bidding-down attack could be accomplished within a spurious hop = somewhere between the originating and terminating end systems, such = that the attacker replaces a stronger offer by a weaker one of the same = protocol family. For the bidding-down attack success, the strength of = the substituted MIKEY protocol matters only as much as its security is = (somewhat) less than the original protocols. If the reduced security = level is sufficient to break MIKEY in any reasonable time, is a = completely different issue. The protected protocol list would not indicate the particular = substitution attack. However, I admit that there are two mechanisms in place that allow the = offerer to detect such an attack: a) The offerer would receive a SDP response from the answerer that = holds a "foreign", non-offered kmgt option. b) MIKEY luckily provides the verification message, unless the MIKEY = key management protocol isn't already two-way. Mechanism a) or b) are the only way for the offerer to detect any = occurred bidding-down attack; the responder has no chance to detect = such an attack just by inspecting the incoming offer. For myself this fact is now clear. So my conclusion is that in fact the = MIKEY verification message has a very strong value in protecting the = offerer against bidding-down attacks. I simply cannot remember right = now, if this has been adequately explained in MIKEY RFC or in the kmext = draft and if that is apparent to the reader. > > My conclusion (needs confirmation) is that the design flaw is that=20 the KMID is on a key management protocol family but it should rather be = on the key management protocol option/varient. > > For MIKEY, the fix should be straightforward: Allocate a KMID for=20 each of the MIKEY protocol variants; i.e. > One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK. ...this protection mechanism is totally inadequate for the case you describe, the "real" security hole remains open even if we were to add this feature. MEU:> hmm, I'm not certain if I understand this fully. Except for the problem that you correctly describe in the following = paragraph, I believe that my proposed solution could at least provide = some value for the answerer to get protection against bidding down = attacks on the MIKEY protocol level, yet clearly not on any = transform/alg level below. This would challenge us to answer the question: Is the proposed yet = non-perfect approach (i.e. allocating several KMIDs) worth the effort? Maybe...when we don't want the entire security protection to depend = just on the offerer, but give the answerer a certain chance at least to = recover on its own. I put this aspect for further discussion among the security experts. Another scenario in which the suggested protection is not enough is as follows: suppose preshared-MIKEY is extended by a cipher/MAC combination which has poor security. It may then not be enough to authenticate the fact MIKEY-preshared was offered, but rather the exact options at the transform level (which *is* done in each a-line individually, but not across a-lines).=20 MEU:> Yes I completely agree to this point. Taken to the most extreme = case this would mean that the entire offering of security parameters = would need to be secured. I clearly think that this is beyond what we = want to achieve. However, we would exclude this as a threat for the same reason as above: if faked MIKEY lines can be inserted by an attacker, the problem is not of bidding-down nature, it is really a fundamental security flaw of the protocol as such. MEU:> not quite. Please see my explanations on the spurious hop, above. Finally, if one is still concerned by this, we would suggest that the Initiator uses MIKEY's option of requesting a verification message back from the Responder. If an attacker modifies the offer to contain something the Initiator actually didn't offer, the response back will be generated by an incorrect method/key, and the Initiator will detect this when checking the response. MEU:> Yes full agreement. Clearly the verification mechanism is a very = powerful tool to protect the offerer from a bidding down attack. = However, the answerer fully depends on the correct reaction and = implementation of the offerer. The answerer has no means to detect an = occurred bidding-down attack on its own. Best, /Mats and MIKEY gang _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 23:14:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20790 for ; Tue, 19 Oct 2004 23:14:08 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK77m-0004fE-ED for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 23:26:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4fd-0007TJ-Vv; Tue, 19 Oct 2004 20:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJygV-0005Ww-Md for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 14:26:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25764 for ; Tue, 19 Oct 2004 14:26:05 -0400 (EDT) Received: from robocat1.securesites.net ([198.66.222.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJysg-0005tP-5n for mmusic@ietf.org; Tue, 19 Oct 2004 14:38:46 -0400 Received: from [127.0.0.1] (adsl-64-171-55-1.dsl.snfc21.pacbell.net [64.171.55.1]) (authenticated bits=0) by robocat1.securesites.net (8.13.1/8.12.11) with ESMTP id i9JIPvbo043915 for ; Tue, 19 Oct 2004 18:25:59 GMT Message-ID: <41755C7C.9060807@i2telecom.com> Date: Tue, 19 Oct 2004 11:27:08 -0700 From: Awais Ali User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org References: <20040824111640.1982.qmail@web40603.mail.yahoo.com> <4174F77E.70807@ericsson.com> In-Reply-To: <4174F77E.70807@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] purpose of derived-from in ICE SDP attribute X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Hi all, I can't seem to figure out the purpose of derived-from attribute in section 9 of draft-ietf-mmusic-ice-02. It is mentioned anywhere in the draft. Can anybody explain that to me? Regards Ali _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 19 23:31:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21699 for ; Tue, 19 Oct 2004 23:31:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK7OR-0004yV-TP for mmusic-web-archive@ietf.org; Tue, 19 Oct 2004 23:44:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4ga-0001df-Bt; Tue, 19 Oct 2004 20:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJzQf-0007Ho-9v for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 15:13:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00901 for ; Tue, 19 Oct 2004 15:13:43 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJzcl-0007HS-Vh for mmusic@ietf.org; Tue, 19 Oct 2004 15:26:25 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61584 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CJzPz-0001AD-E5; Tue, 19 Oct 2004 20:13:11 +0100 In-Reply-To: <4174DB06.40702@ericsson.com> References: <200409201942.PAA05336@ietf.org> <6191FD82-0B51-11D9-9902-000A957FC5F2@csperkins.org> <4174DB06.40702@ericsson.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] Change proposal for draft-ietf-mmusic-sdp-new-20.txt Date: Tue, 19 Oct 2004 20:13:06 +0100 To: Magnus Westerlund X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: "mmusic \(\(E-mail\)\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit On 19 Oct 2004, at 10:14, Magnus Westerlund wrote: > In the work on updating RFC 3267 (AMR and AMR-WB RTP payload format) > which originally defines "a=maxptime" I have recieved a request for > clarification that I think make sense and which do not create any > backwards compatibility issues: > > In Section 6: under attribue "a=maxptime:" > > I would like to rephrase the sentence: > "The time SHOULD be a multiple of the frame size." > > To: > "The time SHOULD be an integer multiple of the frame size. > ^^^^^^^^^ > Comments? Looks reasonable to me. Unless there are objections in the next couple of days, I'll make the change. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 00:32:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26087 for ; Wed, 20 Oct 2004 00:32:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK8Lu-0006LK-BK for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 00:45:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4jn-0005dK-Fu; Tue, 19 Oct 2004 20:53:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK0sl-0004z7-Nd for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 16:46:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11846 for ; Tue, 19 Oct 2004 16:46:51 -0400 (EDT) Received: from webadmin.keyvoice.com ([12.153.69.6] helo=home.ringle.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK14w-00024D-Ml for mmusic@ietf.org; Tue, 19 Oct 2004 16:59:35 -0400 Received: by home.ringle.org (Postfix, from userid 501) id 2E0BBB8648; Tue, 19 Oct 2004 16:46:14 -0400 (EDT) From: Jon Ringle To: mmusic@ietf.org Date: Tue, 19 Oct 2004 16:46:14 -0400 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410191646.14493.ml-mmusic@ringle.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Confusion regarding ICE username fragment X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ml-mmusic@ringle.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit I'm a little confused regarding the use of username fragments in ICE. The following statement is in draft-ietf-mmusic-ice-02, Section 5.3.2: For each local transport address where a STUN server is running, the client MUST choose a username fragment and a password. The username fragment created by the client will be concatenated with the fragment created by its peer. The result will serve as the username provided by its peer in STUN requests. By creating the username as a combination of information from each side of a call, it allows a client to correlate the source of the request with a candidate transport address. This is discussed further below. The username fragment MUST be globally unique, so that no other host will select a username with the same value. This username fragment and password will be passed to its peer in an initiate or accept message. As such, the process described in this section will associate, with each local transport address, a username fragment and password. The client also associates this same username fragment and password with any transport addresses derived from the local transport address. Suppose phone-A has only one local transport address on eth0 and derives a STUN and TURN address from the eth0 local transport address. From what I read above, it seems like only a username fragment and password is chosen only for the eth0 address, and that the derived STUN/TURN addresses use this same username/password. So, this would result in alt's in SDP in the initiate message from phone-A to phone-B like this: a=alt:1 1.0 : PhoneAeth0user password 172.16.1.102 1234 a=alt:2 0.8 : PhoneAeth0user password 1.1.1.4 8801 a=alt:3 0.4 : PhoneAeth0user password 1.1.1.5 3002 This seems to go against the examples that are shown in draft-rosenberg-sipping-nat-scenarios-03, where a separate username fragment is shown for each local and derived addresses. It seems to me that separate username fragments would be needed for each gathered address for correlation to the candidate table. I feel like I am missing a key concept here. Could someone please explain. Thanks, Jon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 01:53:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03247 for ; Wed, 20 Oct 2004 01:53:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK9c2-0008OX-EK for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 02:06:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK8BE-0006n7-QP; Wed, 20 Oct 2004 00:34:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4kK-0006WI-Kh for mmusic@megatron.ietf.org; Tue, 19 Oct 2004 20:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09728 for ; Tue, 19 Oct 2004 20:54:25 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK4wX-0001S6-Jt for mmusic@ietf.org; Tue, 19 Oct 2004 21:07:11 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9K0sMAP016135 for ; Tue, 19 Oct 2004 17:54:22 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5U00HWFVPYXD@gateway2.EECS.Berkeley.EDU> for mmusic@ietf.org; Tue, 19 Oct 2004 16:53:58 -0700 (PDT) Date: Tue, 19 Oct 2004 17:54:21 -0700 From: lazzaro To: mmusic@ietf.org Message-id: <9417291C-2232-11D9-A0DA-00039372C384@eecs.berkeley.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] maxptime X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT Magnus writes: > In the work on updating RFC 3267 (AMR and AMR-WB RTP payload format) > which originally defines "a=maxptime" I have recieved a request for > clarification that I think make sense and which do not create any > backwards compatibility issues: > > In Section 6: under attribue "a=maxptime:" > > I would like to rephrase the sentence: > "The time SHOULD be a multiple of the frame size." > > To: > "The time SHOULD be an integer multiple of the frame size. If maxptime is now considered a parameter for use in all codecs (like the "ptime" it was derived from), shouldn't its definition admit that not all codecs are frame based? The RTP MIDI I-Ds use ptime and maxptime, and RTP MIDI is not frame based ... indeed, a ptime and maxptime of 0 are perfectly valid and useful for RTP MIDI. Zero signals a one-command-per-packet sending style. A MIDI command has no temporal extent -- a packet needs two commands to have non-zero time, as a rule (that has exceptions ...). --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 05:41:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15307 for ; Wed, 20 Oct 2004 05:41:59 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDB1-00045n-46 for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 05:54:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBbG-0005S8-Fv; Wed, 20 Oct 2004 04:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKAKE-0006hw-3Q for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 02:51:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05124 for ; Wed, 20 Oct 2004 02:51:51 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAWF-0000wU-3c for mmusic@ietf.org; Wed, 20 Oct 2004 03:04:39 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9K6pZWR023760 for ; Wed, 20 Oct 2004 08:51:35 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 08:51:35 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4V8F6930; Wed, 20 Oct 2004 08:51:33 +0200 Message-ID: <41760AF4.1010201@ericsson.com> Date: Wed, 20 Oct 2004 08:51:32 +0200 X-Sybari-Trust: 07346ddd bfd556f1 c8fd37db 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: lazzaro Subject: Re: [MMUSIC] maxptime References: <9417291C-2232-11D9-A0DA-00039372C384@eecs.berkeley.edu> In-Reply-To: <9417291C-2232-11D9-A0DA-00039372C384@eecs.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2004 06:51:35.0036 (UTC) FILETIME=[3D5E33C0:01C4B671] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Hi John, The attribute is not intended to exclude non-frame based codecs. However it does in some degree assume that audio content has some type of duration: a=maxptime: The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the packet represents. The time SHOULD be a multiple of the frame size. This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media attribute, and is not dependent on charset. Note that this attribute was introduced after RFC 2327, and non updated implementations will ignore this attribute. We could clarify this so it want be misunderstood. I also received a comment from Dave Singer that "frame size" is not really correct. Thus I think one can modify the sentence to be more clear without affecting the intended semantics: For any frame-based media, the maximum packet time SHOULD be an integer multiple of the frame duration. Is that better? Cheers Magnus lazzaro wrote: > Magnus writes: > > In the work on updating RFC 3267 (AMR and AMR-WB RTP payload format) > > which originally defines "a=maxptime" I have recieved a request for > > clarification that I think make sense and which do not create any > > backwards compatibility issues: > > > > In Section 6: under attribue "a=maxptime:" > > > > I would like to rephrase the sentence: > > "The time SHOULD be a multiple of the frame size." > > > > To: > > "The time SHOULD be an integer multiple of the frame size. > > > If maxptime is now considered a parameter for use in > all codecs (like the "ptime" it was derived from), shouldn't > its definition admit that not all codecs are frame based? > > The RTP MIDI I-Ds use ptime and maxptime, and RTP MIDI > is not frame based ... indeed, a ptime and maxptime of 0 are > perfectly valid and useful for RTP MIDI. Zero signals a > one-command-per-packet sending style. A MIDI command > has no temporal extent -- a packet needs two commands > to have non-zero time, as a rule (that has exceptions ...). > > --- > John Lazzaro > http://www.cs.berkeley.edu/~lazzaro > lazzaro [at] cs [dot] berkeley [dot] edu > --- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 07:36:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23832 for ; Wed, 20 Oct 2004 07:36:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKExX-0006Xh-9Z for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 07:48:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDht-0007jZ-Hv; Wed, 20 Oct 2004 06:28:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKCgx-0002Y9-6W for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 05:23:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13558 for ; Wed, 20 Oct 2004 05:23:32 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKCt5-0003ca-L5 for mmusic@ietf.org; Wed, 20 Oct 2004 05:36:23 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9K9NIWR007245 for ; Wed, 20 Oct 2004 11:23:18 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 11:23:18 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4V8F8H4D; Wed, 20 Oct 2004 11:23:18 +0200 Message-ID: <41762E84.3050207@ericsson.com> Date: Wed, 20 Oct 2004 11:23:16 +0200 X-Sybari-Trust: e08a8c49 bfd556f1 c8fd37db 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? References: <20041019181728.73664.qmail@web53707.mail.yahoo.com> In-Reply-To: <20041019181728.73664.qmail@web53707.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2004 09:23:18.0156 (UTC) FILETIME=[6F4014C0:01C4B686] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit sunil bhargo wrote: > Hi Magnus, > Thanks for the reply. I agree to your > concerns regarding the option 2 of not modifying the > Supported header by the intervening proxy or server. > I am ok with option 1. In case of proxy chain then the > client will receive the common set of features in the > proxy-supported header. But what is the solution about > clients supporting the previous versions ,that is only > the supported header. In that case i think the proxy > should be allowed to write the supported headers. First if the client do not indicate support for the new specification. Then it will ignore the Supported header, because that is also added by this specification. RFC 2326 only has Require and Unsupported to make this negotiation. Thus I don't see a problem with supported. A RFC 2326 client will never add it, and thus will never need to interpret it. If proxy adds the proxy-supported header to a request it should be ignored by the receiving client. It might be an issue if there is a proxy in the chain which do not support the new specification. Thus one should consider using proxy-require: play.basic to ensure that all proxies do correctly handle the supported header. Please note that it will be mandatory to handle the supported and proxy-supported headers. > Just wanted add one thing that the > user/player should never make the bypassing decision > based on the Supported headers feature-tags as > inclusion of any feature-tag in Supported header > should be optional session feature and the > player/client should be able to live with/without this > feature tag. If something is mandatory then it should > be included into require and proxy-require headers. First, I like to clarify that if one uses Supported and proxy-supported it is to find out if the proxies and server do understand a feature that one likes to use. It might be that one requires the feature to work. Therefore I don't think that it is reasonable after a exchange with Supported and Proxy-Supported that results in that a feature is not supported should still do Require and Proxy-Require. Supported is intended to find out things before one actually tries them. Require is to ensure that this functionality is in place as the request actually requires them. Thus as I see it a client may very well decided to bypass a proxy-chain based on the Proxy-Supported header. > Can we add the text that the client is advised to use > only the common set of features in proxy-supported and > supported headers ? > I do agree for a need to add text explaining that feature tags that are classified as needing support by both servers and proxies, needs to considered using the common set from both headers. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 08:45:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28509 for ; Wed, 20 Oct 2004 08:45:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG30-00080q-9U for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 08:58:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF0h-0007mC-9X; Wed, 20 Oct 2004 07:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKDre-0002NN-Bv for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 06:38:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19193 for ; Wed, 20 Oct 2004 06:38:34 -0400 (EDT) Received: from web53701.mail.yahoo.com ([206.190.37.22]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKE3w-0005Eg-Mb for mmusic@ietf.org; Wed, 20 Oct 2004 06:51:25 -0400 Message-ID: <20041020103801.92809.qmail@web53701.mail.yahoo.com> Received: from [202.4.189.74] by web53701.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 03:38:01 PDT Date: Wed, 20 Oct 2004 03:38:01 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? To: Magnus Westerlund In-Reply-To: <41762E84.3050207@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Hi Magnus, thanks for the reply. I agree now on the bypassing decision. but just one clarification below :- > First if the client do not indicate support for the > new specification. > Then it will ignore the Supported header, because > that is also added by > this specification. RFC 2326 only has Require and > Unsupported to make > this negotiation. Thus I don't see a problem with > supported. A RFC 2326 > client will never add it, and thus will never need to > interpret it. If > proxy adds the proxy-supported header to a request it > should be ignored by the receiving client. > It might be an issue if there is a proxy in the chain > which do not > support the new specification. Thus one should > consider using > proxy-require: play.basic to ensure that all proxies > do correctly handle > the supported header. > Please note that it will be mandatory to handle the > supported and > proxy-supported headers. What i meant by backward compatibility is not with RFC2326 but with client complying to rfc2326bis02-07. I am not sure whether a client can say that it complies to a draft. If it can then the client will only send the supported header and no proxy-supported header. So should the new specification proxies fall to not modifying the supported header or should it be modified. thanks, sunil bhargo __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 08:54:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29181 for ; Wed, 20 Oct 2004 08:54:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKGAo-0008Df-4J for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 09:06:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKF2k-0008DZ-L1; Wed, 20 Oct 2004 07:54:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKEDi-0005jd-Nm for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 07:01:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21572 for ; Wed, 20 Oct 2004 07:01:22 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKEQ0-0005s5-Uf for mmusic@ietf.org; Wed, 20 Oct 2004 07:14:14 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9KB1MWR002871 for ; Wed, 20 Oct 2004 13:01:22 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 13:01:22 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4KCB0NCT; Wed, 20 Oct 2004 13:00:57 +0200 Message-ID: <41764569.1040601@ericsson.com> Date: Wed, 20 Oct 2004 13:00:57 +0200 X-Sybari-Trust: 35fe6a9d 8cefd49f fbc7b5b5 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? References: <20041020103801.92809.qmail@web53701.mail.yahoo.com> In-Reply-To: <20041020103801.92809.qmail@web53701.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2004 11:01:22.0794 (UTC) FILETIME=[22C494A0:01C4B694] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, sunil bhargo wrote: > What i meant by backward compatibility is not > with RFC2326 but with client complying to > rfc2326bis02-07. I am not sure whether a client can > say that it complies to a draft. If it can then the > client will only send the supported header and no > proxy-supported header. So should the new > specification proxies fall to not modifying the > supported header or should it be modified. > A draft is a draft and may change at any point in time. If one starts implementing draft documents, one must be ready to update that implementation at any time when updates becomes available. Any draft implementation should not be commerially or large scale deployed at all. To be able to do good technical work we need to possibility to change things, thus we can't have such arguments that we need to preserver compatibility with a previous draft version. Especially not when draft still has some way to go before being ready for WG last call. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 10:21:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07204 for ; Wed, 20 Oct 2004 10:21:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHY6-0001cv-Ai for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 10:34:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGY4-0003ds-Bp; Wed, 20 Oct 2004 09:30:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFrr-0001Zk-Ku for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 08:47:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28611 for ; Wed, 20 Oct 2004 08:46:56 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG4A-00081f-Ut for mmusic@ietf.org; Wed, 20 Oct 2004 08:59:48 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9KCkkdj009431 for ; Wed, 20 Oct 2004 08:46:47 -0400 (EDT) Message-ID: <41765E18.1050900@dynamicsoft.com> Date: Wed, 20 Oct 2004 08:46:16 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE Issue: mid-session connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Folks, One of the big changes in the -02 ICE spec was the addition of mid-session connectivity checks. These checks served several purposes: 1. detection of a network failure that causes an interface to become unreachable 2. in the case of a failure of a nat in the middle of the network, if the nat recovers, or a backup takes its place, a new binding will get assigned, and it can be discovered The particular motivating use case for 2 is an enterprise that is multihomed. It has a NAT on each of its two interfaces to its providers. The enterprise uses the address prefix provided from provider A, and advertises reachability to this prefix into provider B. A client within the enterprise makes a call. The NAT and/or connection to provider A fails. Routing now causes outbound UDP packets to go over the interface to provider B. So, outbound UDP packets from the client now go through this other NAT. It assigns a new binding. With mid-session checks, the new binding can be learned by the peer, and communications established using it. Now, the trick is that, if we are interested in VoIP as a driving use case for this, the amount of time to discover this has to be relatively short. If it takes 30 seconds, the users in the call would have already hung up. That requires the connectivity checks to be sent at a rapid clip. Furthermore, in the case of such a failure, signaling would fail too in all likelihood (depending where the servers are), which would require some SIP operations. So, the issue is, is it worth it? I have gotten a few complaints about the complexity introduced by the mid-session checks. Thus, we have three choices as I see it: 1. remove the checks completely ICE runs only on setup, to do an initial check. RTCP would, for example, allow you to detect some of these failure situations mid-call. Recovery would require re-establishing the call. 2. keep the checks THe draft stays as is 3. Allow for the usage of the checks to be negotiated In case a client doesn't want to implement support for the mid-session checks, we make them optional and allow it to be signaled. I'd prefer NOT to do 3, in the interest of avoiding protocol options. The argument in favor of 1 is primarily one of simplification, and that you will have to make these connectivity checks really fast in order to be responsive enough to really recover from a failure, which could be a problem. As I constantly hear these days that "ICE is too complicated", in the interests of simplification, I'd be game to remove the feature. It could be added back in as an extension later if needed. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 20 10:26:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07878 for ; Wed, 20 Oct 2004 10:26:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKHcK-0001i5-S2 for mmusic-web-archive@ietf.org; Wed, 20 Oct 2004 10:39:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKGZa-00040j-3R; Wed, 20 Oct 2004 09:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKFxe-0002iz-7P for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 08:53:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29129 for ; Wed, 20 Oct 2004 08:52:55 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKG9x-0008C2-HR for mmusic@ietf.org; Wed, 20 Oct 2004 09:05:47 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9KCqjdj009459 for ; Wed, 20 Oct 2004 08:52:45 -0400 (EDT) Message-ID: <41765F7F.3070707@dynamicsoft.com> Date: Wed, 20 Oct 2004 08:52:15 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE issue: STUN vs. STUN over RTP X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Since the last IETF, several folks have independently suggested to me that we tunnel STUN over RTP, and use that for the connectivity checks. The reasoning is that it avoids the ugliness of multiplexing STUN and RTP on the same port. There are pros and cons to doing this: Cons: - STUN responses would end up being in RTP packets sent in the reverse direction, even though RTP is not really a request/response protocol, so its a mismatch there - You'd need to also tunnel STUN over RTCP somehow (app packets?), which is getting really ugly - STUN packets aren't RTP, and things like statistics would get somewhat distorted (less severe if you don't do mid-session checks per my other note). There would be jumps in timestamps that don't really make sense since STUN really isn't real time media - If SRTP is in use, you couldn't process the STUN packets until the SRTP keying had been done. Thats not a big deal, in that ICE requires the exchange of username portions to complete within SIP before the STUN packets can be processed - makes the solution RTP specific Pros: + avoids demuxing STUN and RTP on the same port I think the cons really outweigh the pros, especially if we remove the mid-session checks. As such, I'd like to keep the current STUN approach. Comments? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 07:30:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03726 for ; Thu, 21 Oct 2004 07:30:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbLh-0004z3-E3 for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 07:43:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKTOC-0000gZ-W8; Wed, 20 Oct 2004 23:13:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKIci-0002WN-Pr for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 11:43:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15886 for ; Wed, 20 Oct 2004 11:43:29 -0400 (EDT) Received: from web53707.mail.yahoo.com ([206.190.37.28]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKIp3-0003KH-NE for mmusic@ietf.org; Wed, 20 Oct 2004 11:56:23 -0400 Message-ID: <20041020154258.856.qmail@web53707.mail.yahoo.com> Received: from [202.4.189.74] by web53707.mail.yahoo.com via HTTP; Wed, 20 Oct 2004 08:42:58 PDT Date: Wed, 20 Oct 2004 08:42:58 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] Is Supported Header in RTSP changeable by a proxy ? To: Magnus Westerlund In-Reply-To: <41764569.1040601@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da We have resoloution then if nobody has any additions. --- Magnus Westerlund wrote: > Hi, > > sunil bhargo wrote: > > > > What i meant by backward compatibility is > not > > with RFC2326 but with client complying to > > rfc2326bis02-07. I am not sure whether a client > can > > say that it complies to a draft. If it can then > the > > client will only send the supported header and no > > proxy-supported header. So should the new > > specification proxies fall to not modifying the > > supported header or should it be modified. > > > > A draft is a draft and may change at any point in > time. If one starts > implementing draft documents, one must be ready to > update that > implementation at any time when updates becomes > available. Any draft > implementation should not be commerially or large > scale deployed at all. > To be able to do good technical work we need to > possibility to change > things, thus we can't have such arguments that we > need to preserver > compatibility with a previous draft version. > Especially not when draft > still has some way to go before being ready for WG > last call. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 07:35:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04752 for ; Thu, 21 Oct 2004 07:35:46 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbQp-0005D3-Gu for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 07:48:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUI2-0005e2-Ge; Thu, 21 Oct 2004 00:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKJGM-0008BD-97 for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 12:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20360 for ; Wed, 20 Oct 2004 12:24:26 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKJST-0004HG-2f for mmusic@ietf.org; Wed, 20 Oct 2004 12:37:21 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9KGOBfM020335 for ; Wed, 20 Oct 2004 18:24:11 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 18:24:11 +0200 Received: from ericsson.com (permit156.er.ki.sw.ericsson.se [147.214.97.156]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4KCCCXPL; Wed, 20 Oct 2004 18:24:11 +0200 Message-ID: <4176912B.90104@ericsson.com> Date: Wed, 20 Oct 2004 18:24:11 +0200 X-Sybari-Trust: 17876ded 8cefd49f fbc7b5b5 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Euchner Martin References: <8C878B55C96F924389908D4A7384842A03A02B85@mchh2c7e.mchh.siemens.de> In-Reply-To: <8C878B55C96F924389908D4A7384842A03A02B85@mchh2c7e.mchh.siemens.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-OriginalArrivalTime: 20 Oct 2004 16:24:11.0427 (UTC) FILETIME=[3B5F6F30:01C4B6C1] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.ericsson.se id i9KGOBfM020335 X-Spam-Score: 1.2 (+) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Content-Transfer-Encoding: quoted-printable Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: 9f79b8e383fd3af2b1b5b1d0910f6094 Content-Transfer-Encoding: quoted-printable Hi again Martin, Thanks for your additional thoughts. Indeed, I think we are getting closer, but as you write, there may still be some mutual misunderstandings before we "meet". Hopefully, some more elaboration below brings us even closer... Euchner Martin wrote: > Many thanks to you and the entire MIKEY crew for answering my question. > > On one hand, I understand your response (see my acknowledgement >below), one the other hand put some further comments for discussion and >yet in some other areas I believe that there may be just a resolvable=20 >misunderstanding. > > I'm addressing the issues inline below. > > Cheers > > Martin > > -----Original Message----- > From: Mats N=E4slund [mailto:mats.naslund@ericsson.com] > Sent: Montag, 18. Oktober 2004 11:39 > To: Euchner Martin > Cc: mmusic@ietf.org; Jari Arkko (JO/LMF); Elisabetta Carrara=20 (KI/EAB); Fredrik Lindholm (KI/EAB); Karl Norrman (KI/EAB) > > Subject: Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA=20 considerations section > > > > > Assuming an example where the offerer advertises just 3 MIKEY > protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK, > > > > Then the SDP would hold something like > > a=3Dkey-mgmt:mikey a1234a54... > > a=3Dkey-mgmt:mikey b454646ca54... > > a=3Dkey-mgmt:mikey c95785656ef3.... > > > First of all, why would this be something that ever occurs? > The reason we allow several options is to let the parties > agree on a particular prefered *protocol*, but choosing options > within one and the same protocol is not intended to be done > at this level. > > MEU:> Ok this confirms that kmtext "negotiates" a key management >protocol family, but does not actually negotiate any particular key >management capability. I intentionally put negotiate in quotes, since Well, we would e.g. assume that if a shared key is known, that method would in general be preferred (even if you by chance also know a public key), and the need to negotiate in that "dimension" would be small. Still, we think also that sort of negotiation *could* be done with a security that is not lower than if just single offers were allowed, see below. > this SDP-based negotiation is operating just on the family - level of=20 >the key management protocol but certainly not on protocol capabilities >(such as a particular choice like MIKEY-PK, or even more fine grained >on a crypto algorithm level). So in order to "negotiate" any deeper >than the family-level, kmgtext offers the desired MIKEY protocol >variants in parallel. Unfortunately, this increases the processing time >of the offerer considerably; namely 3 times to instantiate and to >compile 3 different MIKEY key management protocol messages. For the=20 >answerer, the work load is not as high as on the offerer, but still the >base64 decoding requires some more effort than just a quick inspection >of a specific KMID would cost; so this latter point is really a minor=20 >issue. Yes, if you really don't have any clue what the responder supports/prefers, you *could* trade the number of single messages for the amount of processing involved in a producing a single, but larger multi-offer. > > I should clearly say, that I don't see any better alternative for a >full 2-way handshake negotiation process yet a 4-way handshake would >not face the parallel explosion property. > > > (Anyway, let's assume it can happen...) > > > > > and the generated protocol list would be "mikey;mikey;mikey", where > 'mikey' represents the allocated KMID value for the MIKEY protocol=20 family. > > > Right. > > > > > Q1) In the context of bidding-down protection, what kind of securit= y > does this list actually provide? > > > > I believe that an attacker could easily substitute another, weak 4t= h > mikey key management protocol ("mikey-password") against one of the > other three offered ones; yet the (MIKEY) protected protocol list woul= d > remain the same and the answer would not be able to detect the attack. > > > Okay, let's assume he can. To accomplish this, the "mikey-password" > variant needs to be so weak that he can fake the authentiction data of > the a-line where this is inserted. That is, the authentication mechani= sm > of the password variant is completely insecure. But if this is so, the > attacker does not even need the "real" Initiator to be on-line: he can > at any point in time impersonate the real Initiator, faking MIKEY > messages using the password variant. Therefore... > > MEU:> Here I sense a minor misunderstanding. I'm clearly not >questioning the security of any MIKEY protocol nor am I saying that any >MIKEY protocol is any close to being weak that it could be broken. > > My only concern in the context of a bidding-down attack is, that the=20 >bidding-down attack could be accomplished within a spurious hop What do you mean by "spurious hop" ? >somewhere between the originating and terminating end systems, such >that the attacker replaces a stronger offer by a weaker one of the same >protocol family. For the bidding-down attack success, the strength of Neglecting that we don't understand "spurious hop", we still think that the attack you describe is of the following form: 1. The Initiator makes an offer containing m > 1 MIKEY alternatives/lines. 2. Somehow, along the path, at least one of the m MIKEY offers get replaced by another (weaker) MIKEY offer that was not in the original offer. Correct? If so, let's call the weak MIKEY variant "MIKEY-X", be it password based or otherwise. Now we need to ask, how could it be that the inserted MIKEY-X offer gets accepted as authentic by the Responder? As we see it, that would only be possible if either: A) the MIKEY-X offer is a replay of an old offer (which would normally be taken care of by MIKEY-X replay protection), or, B) The MIKEY-X option is so weak in itself that it is possible to fake MIKEY-X messages without even resorting on replay. But if either of these would be possible, there would be a flaw in that specific MIKEY-X variant, and it really doesn't matter that there were more than one offer in the original message: the attacker could fake MIKEY-X offers according to that (single) MIKEY-X version at any point in time, right? The real Initiator doesn't even need to be on-line. Thus, you *could* say that you have a bidding down attack, but that is not *the* real problem. The problem is more fundamental than that. Also, in addition (as we seem to agree), the bidding-down variant of the=20 attack can be discovered using the verification option. (However, the more basic "faked-offer" is not mitigated by the V-message.) > the substituted MIKEY protocol matters only as much as its security is >(somewhat) less than the original protocols. If the reduced security > >level is sufficient to break MIKEY in any reasonable time, is a >completely different issue. We think (see above) that it isn't enough if the substituted offers are only "somewhat" less secure, they would need to be quite badly insecure, otherwise the substitution as such would be impossible. > > The protected protocol list would not indicate the particular=20 >substitution attack. Correct. But even single offers containing only one MIKEY line could be faked. > > However, I admit that there are two mechanisms in place that allow the >offerer to detect such an attack: > a) The offerer would receive a SDP response from the answerer that >holds a "foreign", non-offered kmgt option. > b) MIKEY luckily provides the verification message, unless the MIKEY >key management protocol isn't already two-way. > > Mechanism a) or b) are the only way for the offerer to detect any >occurred bidding-down attack; the responder has no chance to detect >such an attack just by inspecting the incoming offer. Yes. But even so, attacks remain possible by just faking *single* offers based on the weak variant. > > For myself this fact is now clear. So my conclusion is that in fact >the MIKEY verification message has a very strong value in protecting >the offerer against bidding-down attacks. I simply cannot remember >right now, if this has been adequately explained in MIKEY RFC or in the >kmext draft and if that is apparent to the reader. Maybe not...but this was clearly one reason for adding it as an option. > > > > My conclusion (needs confirmation) is that the design flaw is that > the KMID is on a key management protocol family but it should rather >be > on the key management protocol option/varient. > > > > For MIKEY, the fix should be straightforward: Allocate a KMID for > each of the MIKEY protocol variants; i.e. > > One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK. > > > ...this protection mechanism is totally inadequate for the case > you describe, the "real" security hole remains open even if > we were to add this feature. > > MEU:> hmm, I'm not certain if I understand this fully. > Except for the problem that you correctly describe in the following >paragraph, I believe that my proposed solution could at least provide >some value for the answerer to get protection against bidding down >attacks on the MIKEY protocol level, yet clearly not on any >transform/alg level below. It is not clear it helps, if there is even a single very insecure variant. Also, if a single, otherwise secure, variant contains insecure "sub-options" you have an issue. We are therefore sceptic to what it adds. > > This would challenge us to answer the question: Is the proposed yet >non-perfect approach (i.e. allocating several KMIDs) worth the effort? > > Maybe...when we don't want the entire security protection to depend >just on the offerer, but give the answerer a certain chance at least to >recover on its own. > > I put this aspect for further discussion among the security experts. > We are listening to other possible feedback. We hope we have clarified why *we* think the suggested approach protects against "relevant" attacks. > > Another scenario in which the suggested protection is not enough > is as follows: suppose preshared-MIKEY is extended by a cipher/MAC > combination which has poor security. It may then not be enough to > authenticate the fact MIKEY-preshared was offered, but rather the > exact options at the transform level (which *is* done in each a-line > individually, but not across a-lines). > MEU:> Yes I completely agree to this point. Taken to the most extreme >case this would mean that the entire offering of security parameters >would need to be secured. I clearly think that this is beyond what we=20 >want to achieve. Ok. > > However, we would exclude this > as a threat for the same reason as above: if faked MIKEY lines can > be inserted by an attacker, the problem is not of bidding-down nature, > it is really a fundamental security flaw of the protocol as such. > > MEU:> not quite. Please see my explanations on the spurious hop, >abov= e. We don't see how that could happen, or, to be precise, if it *could* happen, even simpler, non-bidding-down attacks would occur. > > Finally, if one is still concerned by this, we would suggest that > the Initiator uses MIKEY's option of requesting a verification message > back from the Responder. If an attacker modifies the offer to contain > something the Initiator actually didn't offer, the response back will > be generated by an incorrect method/key, and the Initiator will > detect this when checking the response. > > MEU:> Yes full agreement. Clearly the verification mechanism is a very >powerful tool to protect the offerer from a bidding down attack. >However, the answerer fully depends on the correct reaction and >implementation of the offerer. The answerer has no means to detect an >occurred bidding-down attack on its own. > Fully agree. Cheers /Mats and MIKEY gang _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 07:41:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05993 for ; Thu, 21 Oct 2004 07:41:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbWt-0005Ud-H1 for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 07:54:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUMT-0000Et-V2; Thu, 21 Oct 2004 00:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKUM-0006rp-UU for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 13:43:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01225 for ; Wed, 20 Oct 2004 13:43:00 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKgh-00071O-7Y for mmusic@ietf.org; Wed, 20 Oct 2004 13:55:54 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9KHgoXo000044; Wed, 20 Oct 2004 10:42:51 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5W00H4E6EOXD@gateway2.EECS.Berkeley.EDU>; Wed, 20 Oct 2004 09:42:24 -0700 (PDT) Date: Wed, 20 Oct 2004 10:42:49 -0700 From: lazzaro Subject: Re: [MMUSIC] maxptime In-reply-to: <41760AF4.1010201@ericsson.com> To: Magnus Westerlund Message-id: <75B73F9E-22BF-11D9-A6E7-00039372C384@eecs.berkeley.edu> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <9417291C-2232-11D9-A0DA-00039372C384@eecs.berkeley.edu> <41760AF4.1010201@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT On Oct 19, 2004, at 11:51 PM, Magnus Westerlund wrote: > The attribute is not intended to exclude non-frame based codecs. > However it does in some degree assume that audio content has some type > of duration: The RTP MIDI payload's duration is always has a defined value. It just so happens that 0 ms is an acceptable value. So, as long as 0 ms is an acceptable maxptime duration its OK by me. 0 ms needn't be explicitly permitted in the text, but it should not be explicitly forbidden. > For any frame-based media, the maximum packet time SHOULD be an > integer multiple of the frame duration. > > Is that better? Yes, sounds good to me. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 08:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10304 for ; Thu, 21 Oct 2004 08:00:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbov-0006l3-DR for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 08:13:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKanx-0001fC-LN; Thu, 21 Oct 2004 07:08:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKLkz-0008Ax-DI for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 15:04:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12086 for ; Wed, 20 Oct 2004 15:04:13 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLxL-0001rP-BG for mmusic@ietf.org; Wed, 20 Oct 2004 15:17:08 -0400 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9KJ48fO019156; Wed, 20 Oct 2004 21:04:09 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id i9KJ48BO002018; Wed, 20 Oct 2004 21:04:08 +0200 Received: from mchh273e.mchh.siemens.de (mchh273e.mchh.siemens.de [139.21.200.83]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i9KJ4817005101; Wed, 20 Oct 2004 21:04:08 +0200 Received: by mchh273e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Wed, 20 Oct 2004 21:04:07 +0200 Message-ID: <8C878B55C96F924389908D4A7384842A03A02B9B@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: =?ISO-8859-1?Q?=27Mats_N=E4slund=27?= , Euchner Martin Date: Wed, 20 Oct 2004 21:04:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 1.2 (+) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] RE: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Mats, Once again many thanks for your good answers that indeed clarify a lot of the misunderstandings. To quickly summarize: I believe that we are already very close in our views; I don't see any real disagreement. However, I see some further related issues on how the answerer has implemented its system. Originally, I had the "insecure implementation" in mind, yet it was not immediately apparent to me that this is the main cause of the problem. I would at least ask for your confirmation, if that is correct; see the longer added statements with the counter example in the middle of the email. Cherio Martin. > MEU:> Ok this confirms that kmtext "negotiates" a key management >protocol family, but does not actually negotiate any particular key >management capability. I intentionally put negotiate in quotes, since Well, we would e.g. assume that if a shared key is known, that method would in general be preferred (even if you by chance also know a public key), and the need to negotiate in that "dimension" would be small. Still, we think also that sort of negotiation *could* be done with a security that is not lower than if just single offers were allowed, see below. MEU: ok. > My only concern in the context of a bidding-down attack is, that the >bidding-down attack could be accomplished within a spurious hop What do you mean by "spurious hop" ? MEU:> sorry for not having explained the attack scenario. It is exactly the case that you showed in 1. and in 2, where an evil Eve who is not trusted by the offerer nor the answerer runs a modification/substitution attack on at least one SDP a-line. >somewhere between the originating and terminating end systems, such >that the attacker replaces a stronger offer by a weaker one of the same >protocol family. For the bidding-down attack success, the strength of Neglecting that we don't understand "spurious hop", we still think that the attack you describe is of the following form: 1. The Initiator makes an offer containing m > 1 MIKEY alternatives/lines. 2. Somehow, along the path, at least one of the m MIKEY offers get replaced by another (weaker) MIKEY offer that was not in the original offer. Correct? MEU:> yes exactly. If so, let's call the weak MIKEY variant "MIKEY-X", be it password based or otherwise. Now we need to ask, how could it be that the inserted MIKEY-X offer gets accepted as authentic by the Responder? As we see it, that would only be possible if either: A) the MIKEY-X offer is a replay of an old offer (which would normally be taken care of by MIKEY-X replay protection), or, MEU: actually I had in mind just this case as I did not assume case B to happen (so my assumption is also along the lines that MIKEY-X still provides some meaningful security level, yet it is possibly lower in security level than any of the current MIKEY protocol variants.) B) The MIKEY-X option is so weak in itself that it is possible to fake MIKEY-X messages without even resorting on replay. MEU:> You are right that this case would also exist. But if either of these would be possible, there would be a flaw in that specific MIKEY-X variant, and it really doesn't matter that there were more than one offer in the original message: the attacker could fake MIKEY-X offers according to that (single) MIKEY-X version at any point in time, right? The real Initiator doesn't even need to be on-line. Thus, you *could* say that you have a bidding down attack, but that is not *the* real problem. The problem is more fundamental than that. MEU: I tend to agree with that given that Eve somehow must have substituted actually a replayed MIKEY protocol run. I really cannot think of any much different attack right now. Now if Eve had done so, then the answerer could detect this attack, by verification that the integrity of >each< offered MIKEY protocol holds valid. For the replayed option, the verification would fail (e.g. re-used nonce or expired timestamp etc). So I agree with you that the answerer has a real chance to detect a bidding-down attack. This is good and removes my original concern. New concern: Unfortunately, this comes at a high price; namely the answerer MUST implement all MIKEY protocol variants even those that MIKEY calls just optional to implement such as MIKEY-DHSIGN, in order to be able to protect against bidding-down attacks. Right? I cannot fully believe this to be true right now, as this questions the choice of making certain MIKEY protocols optional altogether. Why is it so? So the answerer MUST first verify all received MIKEY protocol offers, and just after that actually would decide which option to choose (authenticate first then policy decide). In fact, doing it the other way round (i.e. 1st make protocol choice then verify that the choice is authentic) would be insecure, even if the choice is not the replayed protocol offer! See counter example: Assume that the offerer provides 3 alternatives: A1, A2, A3 where A1 < A2 < A3 and "<" means security level is lower than. Assume further that Eve substitutes B1 against A1 somewhere between the offerer and the answerer and that B1 < A1. Now assume further the security policy of the answerer is such that the answerer picks the medium offered option; i.e. discarding the highest and the lowest offered option; so in the case without attack, the decision taken is A2. (Please don't ask me if such a security policy is any realistic or why such a policy would make sense). In the case where Eve attacks with a substitute B1 for A3, and the answerer does not verify the security validity first of A1, B1, and A2, the policy decision would pick A1 now. The answerer would not detect the successful bidding-down attack just by verifying A1 which is of course correct. The offerer is also not able to detect the occurred bidding-down attack even with a verification message response. Unfortunately, the insecure variant is so much more compelling from the performance and implementation point of view that incorrect implementations could be tricked at least in certain cases depending on the security policy. Unless I'm badly missing the point here (perhaps it's too late already?), I believe the correct behaviour of the answerer is not immediately obvious to everyone; and thus, it may be more than worth to document the correct behaviour in the security consideration section. BTW: I also forgot to clarify in my previous email, what I understand as a successful bidding-down attack: This is an outcome of a negotiation procedure where the offerer and answerer (with the "help" of some attacker) agree on a security option that yields a less security level than without the attacker. The successful bidding-down attack does not imply that any security protocol has been broken nor that the reduced security option would actually be subject to a (feasible) attack. Also, in addition (as we seem to agree), the bidding-down variant of the attack can be discovered using the verification option. (However, the more basic "faked-offer" is not mitigated by the V-message.) > the substituted MIKEY protocol matters only as much as its security is >(somewhat) less than the original protocols. If the reduced security > >level is sufficient to break MIKEY in any reasonable time, is a >completely different issue. We think (see above) that it isn't enough if the substituted offers are only "somewhat" less secure, they would need to be quite badly insecure, otherwise the substitution as such would be impossible. > MEU: I agree with you, except the issue explained above. > The protected protocol list would not indicate the particular >substitution attack. Correct. But even single offers containing only one MIKEY line could be faked. MEU:> Yes ok, yet such cases could be detected with the V-message. > > However, I admit that there are two mechanisms in place that allow the >offerer to detect such an attack: > a) The offerer would receive a SDP response from the answerer that >holds a "foreign", non-offered kmgt option. > b) MIKEY luckily provides the verification message, unless the MIKEY >key management protocol isn't already two-way. > > Mechanism a) or b) are the only way for the offerer to detect any >occurred bidding-down attack; the responder has no chance to detect >such an attack just by inspecting the incoming offer. Yes. But even so, attacks remain possible by just faking *single* offers based on the weak variant. MEU:> ok. > > For myself this fact is now clear. So my conclusion is that in fact >the MIKEY verification message has a very strong value in protecting >the offerer against bidding-down attacks. I simply cannot remember >right now, if this has been adequately explained in MIKEY RFC or in the >kmext draft and if that is apparent to the reader. Maybe not...but this was clearly one reason for adding it as an option. MEU: ok. > > > > My conclusion (needs confirmation) is that the design flaw is that > the KMID is on a key management protocol family but it should rather >be > on the key management protocol option/varient. > > > > For MIKEY, the fix should be straightforward: Allocate a KMID for > each of the MIKEY protocol variants; i.e. > > One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK. > > > ...this protection mechanism is totally inadequate for the case > you describe, the "real" security hole remains open even if > we were to add this feature. > > MEU:> hmm, I'm not certain if I understand this fully. > Except for the problem that you correctly describe in the following >paragraph, I believe that my proposed solution could at least provide >some value for the answerer to get protection against bidding down >attacks on the MIKEY protocol level, yet clearly not on any >transform/alg level below. It is not clear it helps, if there is even a single very insecure variant. Also, if a single, otherwise secure, variant contains insecure "sub-options" you have an issue. We are therefore sceptic to what it adds. MEU:> Yes I understand your hesitations now. > > This would challenge us to answer the question: Is the proposed yet >non-perfect approach (i.e. allocating several KMIDs) worth the effort? > > Maybe...when we don't want the entire security protection to depend >just on the offerer, but give the answerer a certain chance at least to >recover on its own. > > I put this aspect for further discussion among the security experts. > We are listening to other possible feedback. We hope we have clarified why *we* think the suggested approach protects against "relevant" attacks. MEU:> I appreciate any further views. > > Another scenario in which the suggested protection is not enough > is as follows: suppose preshared-MIKEY is extended by a cipher/MAC > combination which has poor security. It may then not be enough to > authenticate the fact MIKEY-preshared was offered, but rather the > exact options at the transform level (which *is* done in each a-line > individually, but not across a-lines). > MEU:> Yes I completely agree to this point. Taken to the most extreme >case this would mean that the entire offering of security parameters >would need to be secured. I clearly think that this is beyond what we >want to achieve. Ok. > > However, we would exclude this > as a threat for the same reason as above: if faked MIKEY lines can > be inserted by an attacker, the problem is not of bidding-down nature, > it is really a fundamental security flaw of the protocol as such. > > MEU:> not quite. Please see my explanations on the spurious hop, >above. We don't see how that could happen, or, to be precise, if it *could* happen, even simpler, non-bidding-down attacks would occur. MEU:> yes, possibly. I've not analyzed the situation what all could go wrong, if Eve actually attacks the SDP but I believe it could get pretty nasty from the security point of view. > > Finally, if one is still concerned by this, we would suggest that > the Initiator uses MIKEY's option of requesting a verification message > back from the Responder. If an attacker modifies the offer to contain > something the Initiator actually didn't offer, the response back will > be generated by an incorrect method/key, and the Initiator will > detect this when checking the response. > > MEU:> Yes full agreement. Clearly the verification mechanism is a very >powerful tool to protect the offerer from a bidding down attack. >However, the answerer fully depends on the correct reaction and >implementation of the offerer. The answerer has no means to detect an >occurred bidding-down attack on its own. > Fully agree. MEU> Excellent! Cheers /Mats and MIKEY gang _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 08:26:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14796 for ; Thu, 21 Oct 2004 08:26:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcEN-0007pT-OZ for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 08:39:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKb3B-0005P7-Tc; Thu, 21 Oct 2004 07:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKROC-0007PK-9R for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 21:05:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00266 for ; Wed, 20 Oct 2004 21:05:05 -0400 (EDT) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKRad-00071S-2D for mmusic@ietf.org; Wed, 20 Oct 2004 21:18:03 -0400 Received: from zrtpd0j9.us.nortel.com (zrtpd0j9.us.nortel.com [47.140.203.27]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9L14RY24073; Wed, 20 Oct 2004 21:04:27 -0400 (EDT) Received: by zrtpd0j9.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Oct 2004 21:04:27 -0400 Message-ID: <1ECE0EB50388174790F9694F77522CCFD4E990@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Jonathan Rosenberg'" , "'IETF MMUSIC WG'" Subject: RE: [MMUSIC] ICE Issue: mid-session connectivity checks Date: Wed, 20 Oct 2004 21:04:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1760170510==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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. --===============1760170510== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B709.E17FACE6" 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_01C4B709.E17FACE6 Content-Type: text/plain I vote for 1. Note that 1 could be dealt with at the application layer. So while it does indeed mean that the session would be re-established, it doen't NECESSARILY mean that the use would hang-up the call. You could in theory re-establish it without hanging-up. So instead of saying "Recovery would require re-establishing the call" I'd say "Recovery would require re-establishing the session". In fact, couldn't we just do a new Offer/Answer? > -----Original Message----- > From: mmusic-bounces@ietf.org > [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Wednesday, October 20, 2004 05:46 > To: IETF MMUSIC WG > Subject: [MMUSIC] ICE Issue: mid-session connectivity checks > > > Folks, > > One of the big changes in the -02 ICE spec was the addition of > mid-session connectivity checks. These checks served several purposes: > > 1. detection of a network failure that causes an interface to become > unreachable > > 2. in the case of a failure of a nat in the middle of the network, if > the nat recovers, or a backup takes its place, a new binding will get > assigned, and it can be discovered > > > The particular motivating use case for 2 is an enterprise that is > multihomed. It has a NAT on each of its two interfaces to its > providers. > The enterprise uses the address prefix provided from provider A, and > advertises reachability to this prefix into provider B. A > client within > the enterprise makes a call. The NAT and/or connection to provider A > fails. Routing now causes outbound UDP packets to go over the > interface > to provider B. So, outbound UDP packets from the client now > go through > this other NAT. It assigns a new binding. With mid-session > checks, the > new binding can be learned by the peer, and communications > established > using it. > > Now, the trick is that, if we are interested in VoIP as a driving use > case for this, the amount of time to discover this has to be > relatively > short. If it takes 30 seconds, the users in the call would > have already > hung up. That requires the connectivity checks to be sent at a rapid > clip. Furthermore, in the case of such a failure, signaling > would fail > too in all likelihood (depending where the servers are), which would > require some SIP operations. > > So, the issue is, is it worth it? I have gotten a few > complaints about > the complexity introduced by the mid-session checks. Thus, we > have three > choices as I see it: > > 1. remove the checks completely > > ICE runs only on setup, to do an initial check. RTCP would, > for example, > allow you to detect some of these failure situations > mid-call. Recovery > would require re-establishing the call. > > 2. keep the checks > > THe draft stays as is > > 3. Allow for the usage of the checks to be negotiated > > In case a client doesn't want to implement support for the > mid-session > checks, we make them optional and allow it to be signaled. > > > I'd prefer NOT to do 3, in the interest of avoiding protocol options. > The argument in favor of 1 is primarily one of > simplification, and that > you will have to make these connectivity checks really fast > in order to > be responsive enough to really recover from a failure, which > could be a > problem. > > As I constantly hear these days that "ICE is too complicated", in the > interests of simplification, I'd be game to remove the > feature. It could > be added back in as an extension later if needed. > > Comments? > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > ------_=_NextPart_001_01C4B709.E17FACE6 Content-Type: text/html RE: [MMUSIC] ICE Issue: mid-session connectivity checks

I vote for 1.

Note that 1 could be dealt with at the application layer. So while it does indeed
mean that the session would be re-established, it doen't NECESSARILY mean that
the use would hang-up the call. You could in theory re-establish it without
hanging-up.

So instead of saying "Recovery would require re-establishing the call" I'd say
"Recovery would require re-establishing the session".

In fact, couldn't we just do a new Offer/Answer?




> -----Original Message-----
> From: mmusic-bounces@ietf.org
> [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Rosenberg
> Sent: Wednesday, October 20, 2004 05:46
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE Issue: mid-session connectivity checks
>
>
> Folks,
>
> One of the big changes in the -02 ICE spec was the addition of
> mid-session connectivity checks. These checks served several purposes:
>
> 1. detection of a network failure that causes an interface to become
> unreachable
>
> 2. in the case of a failure of a nat in the middle of the network, if
> the nat recovers, or a backup takes its place, a new binding will get
> assigned, and it can be discovered
>
>
> The particular motivating use case for 2 is an enterprise that is
> multihomed. It has a NAT on each of its two interfaces to its
> providers.
> The enterprise uses the address prefix provided from provider A, and
> advertises reachability to this prefix into provider B. A
> client within
> the enterprise makes a call. The NAT and/or connection to provider A
> fails. Routing now causes outbound UDP packets to go over the
> interface
> to provider B. So, outbound UDP packets from the client now
> go through
> this other NAT. It assigns a new binding. With mid-session
> checks, the
> new binding can be learned by the peer, and communications
> established
> using it.
>
> Now, the trick is that, if we are interested in VoIP as a driving use
> case for this, the amount of time to discover this has to be
> relatively
> short. If it takes 30 seconds, the users in the call would
> have already
> hung up. That requires the connectivity checks to be sent at a rapid
> clip. Furthermore, in the case of such a failure, signaling
> would fail
> too in all likelihood (depending where the servers are), which would
> require some SIP operations.
>
> So, the issue is, is it worth it? I have gotten a few
> complaints about
> the complexity introduced by the mid-session checks. Thus, we
> have three
> choices as I see it:
>
> 1. remove the checks completely
>
> ICE runs only on setup, to do an initial check. RTCP would,
> for example,
> allow you to detect some of these failure situations
> mid-call. Recovery
> would require re-establishing the call.
>
> 2. keep the checks
>
> THe draft stays as is
>
> 3. Allow for the usage of the checks to be negotiated
>
> In case a client doesn't want to implement support for the
> mid-session
> checks, we make them optional and allow it to be signaled.
>
>
> I'd prefer NOT to do 3, in the interest of avoiding protocol options.
> The argument in favor of 1 is primarily one of
> simplification, and that
> you will have to make these connectivity checks really fast
> in order to
> be responsive enough to really recover from a failure, which
> could be a
> problem.
>
> As I constantly hear these days that "ICE is too complicated", in the
> interests of simplification, I'd be game to remove the
> feature. It could
> be added back in as an extension later if needed.
>
> Comments?
>
> -Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Director, Service Provider VoIP Architecture   Parsippany, NJ
> 07054-2711
> Cisco Systems
> jdrosen@dynamicsoft.com                        FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>

------_=_NextPart_001_01C4B709.E17FACE6-- --===============1760170510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1760170510==-- From mmusic-bounces@ietf.org Thu Oct 21 08:36:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16966 for ; Thu, 21 Oct 2004 08:36:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcNN-0008LI-6s for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 08:49:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbAA-0005e1-EM; Thu, 21 Oct 2004 07:31:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKTwZ-0002SK-Uv for mmusic@megatron.ietf.org; Wed, 20 Oct 2004 23:48:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21469 for ; Wed, 20 Oct 2004 23:48:43 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKU91-00052G-HB for mmusic@ietf.org; Thu, 21 Oct 2004 00:01:44 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9L3mTdj012764; Wed, 20 Oct 2004 23:48:30 -0400 (EDT) Message-ID: <41773170.5060203@dynamicsoft.com> Date: Wed, 20 Oct 2004 23:48:00 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Awais Ali Subject: Re: [MMUSIC] purpose of derived-from in ICE SDP attribute References: <20040824111640.1982.qmail@web40603.mail.yahoo.com> <4174F77E.70807@ericsson.com> <41755C7C.9060807@i2telecom.com> In-Reply-To: <41755C7C.9060807@i2telecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit This attribute is a leftover from previous versions and is not needed. It'll be removed in the next rev of the draft. Thanks, Jonathan R. Awais Ali wrote: > Hi all, > > I can't seem to figure out the purpose of derived-from attribute in > section 9 of draft-ietf-mmusic-ice-02. It is mentioned anywhere in the > draft. Can anybody explain that to me? > > Regards > Ali > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 08:45:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19177 for ; Thu, 21 Oct 2004 08:45:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcWm-0000WQ-SB for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 08:58:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbM3-0001QY-3B; Thu, 21 Oct 2004 07:43:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKVsS-0004RF-BH for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 01:52:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28095 for ; Thu, 21 Oct 2004 01:52:37 -0400 (EDT) Received: from sightspeed.com ([65.241.182.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKW4w-0006xj-0T for mmusic@ietf.org; Thu, 21 Oct 2004 02:05:38 -0400 Received: from [192.168.1.26] (host51.sightspeed.com [65.241.182.51]) (AUTH: PLAIN aron, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by sightspeed.com with esmtp; Wed, 20 Oct 2004 22:52:37 -0700 id 00000079.41774EA5.00001099 Message-ID: <41774E9C.30208@sightspeed.com> Date: Wed, 20 Oct 2004 22:52:28 -0700 From: Aron Rosenberg Organization: SightSpeed Inc. User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: ICE Issue: mid-session connectivity checks X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: aron@sightspeed.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Jonathan, I agree with you that we should remove the mid-call checks. In addition to points that you raised, they also make running ICE with non RTP media protocols much cleaner. Aron Rosenberg Founder and CTO SightSpeed Inc. >In case a client doesn't want to implement support for the mid-session >checks, we make them optional and allow it to be signaled. > > >I'd prefer NOT to do 3, in the interest of avoiding protocol options. >The argument in favor of 1 is primarily one of simplification, and that >you will have to make these connectivity checks really fast in order to >be responsive enough to really recover from a failure, which could be a >problem. > >As I constantly hear these days that "ICE is too complicated", in the >interests of simplification, I'd be game to remove the feature. It could >be added back in as an extension later if needed. > >Comments? > >-Jonathan R. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 08:48:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19779 for ; Thu, 21 Oct 2004 08:48:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcZ2-0000hX-Nu for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 09:01:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbNS-0004bl-Ir; Thu, 21 Oct 2004 07:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKXdo-00053y-HQ for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 03:45:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18159 for ; Thu, 21 Oct 2004 03:45:37 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKXqH-000075-Qn for mmusic@ietf.org; Thu, 21 Oct 2004 03:58:39 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9L7jafM000348 for ; Thu, 21 Oct 2004 09:45:36 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 09:45:35 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJRR1XF5; Thu, 21 Oct 2004 09:45:35 +0200 Message-ID: <4177691F.9090800@ericsson.com> Date: Thu, 21 Oct 2004 09:45:35 +0200 X-Sybari-Trust: 2e269af0 8cefd49f 00b34519 00000138 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: lazzaro Subject: Re: [MMUSIC] maxptime References: <75B73F9E-22BF-11D9-A6E7-00039372C384@eecs.berkeley.edu> In-Reply-To: <75B73F9E-22BF-11D9-A6E7-00039372C384@eecs.berkeley.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 07:45:35.0876 (UTC) FILETIME=[F378E440:01C4B741] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Hi John, lazzaro wrote: > > The RTP MIDI payload's duration is always has a defined value. > It just so happens that 0 ms is an acceptable value. > > So, as long as 0 ms is an acceptable maxptime duration its OK > by me. 0 ms needn't be explicitly permitted in the text, but it should > not > be explicitly forbidden. > I think the usage of maxptime=0 may be a bit problematic. A interpretation is that no audio can be included in the packet, as no audio duration is allowed. I see that you have made another interpretation in the MIDI draft (draft-ietf-avt-rtp-midi-format-06): "0 ms is a reasonable media time value for MIDI packets. In a packet with a 0 ms media time, all commands execute at the instant coded by the packet timestamp. Prohibitions in [13] against 0 ms ptime values are not relevant for MIDI streams, and may be ignored." An RTP timestamp tick is strictly not an instant, it has a duration equal to 1/(RTP timestamp rate). However these is my interpretation. maxptime was never intended for this usage, where you would have interest to limit the duration to smaller intervals than a 1 ms. We where mostly thinking of the smallest units as something like 5 ms or so. Is really your intention of using maxptime=0 that for each timestamp tick there is a command(s), a new packet should be sent? I can understand using ptime=0 to recommend that you do this behaviour but using maxptime to enforce the behaviour? Another question is how well parsers out there will handle 0. Hopefully well, but I am not certain. Especially any that is primarily to handle Offer/Answer, where a normative MUST be larger than 0 is present. I think you should consider the impact on interoperability. So lets try to sort this out by answering some questions: - How big is the need to be able to specify ptime=0 and maxptime=0, and what is the effect is the smallest one can use is ptime=1? - Do any implementers of generic SDP parsers have any problems with ptime or maxptime equals 0? - Why does RFC 3264 have a normative MUST against using ptime=0? - Any further considerations? If the answer to the above questions and any other input indicates that this is reasonable to do this, then I think a clarification is in order to the parameters about the interpretation of 0. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 09:21:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26761 for ; Thu, 21 Oct 2004 09:21:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKd5p-0002NV-8v for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 09:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcaP-0007h7-C0; Thu, 21 Oct 2004 09:02:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbUf-0000Ex-Po for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 07:52:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07866 for ; Thu, 21 Oct 2004 07:52:32 -0400 (EDT) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbh6-0006AH-U2 for mmusic@ietf.org; Thu, 21 Oct 2004 08:05:35 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 8812B2FFA14D; Thu, 21 Oct 2004 04:52:17 -0700 (PDT) Received: from [10.1.28.2] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id B67802FFA137; Thu, 21 Oct 2004 04:52:12 -0700 (PDT) Message-ID: <4177A2F9.5080907@acm.org> Date: Thu, 21 Oct 2004 04:52:25 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks References: <41765E18.1050900@dynamicsoft.com> In-Reply-To: <41765E18.1050900@dynamicsoft.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.implementers.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit I would prefer to keep the checks - choice 2. Jonathan Rosenberg wrote: > Folks, > > One of the big changes in the -02 ICE spec was the addition of > mid-session connectivity checks. These checks served several purposes: > > 1. detection of a network failure that causes an interface to become > unreachable > > 2. in the case of a failure of a nat in the middle of the network, if > the nat recovers, or a backup takes its place, a new binding will get > assigned, and it can be discovered > > > The particular motivating use case for 2 is an enterprise that is > multihomed. It has a NAT on each of its two interfaces to its providers. > The enterprise uses the address prefix provided from provider A, and > advertises reachability to this prefix into provider B. A client within > the enterprise makes a call. The NAT and/or connection to provider A > fails. Routing now causes outbound UDP packets to go over the interface > to provider B. So, outbound UDP packets from the client now go through > this other NAT. It assigns a new binding. With mid-session checks, the > new binding can be learned by the peer, and communications established > using it. > > Now, the trick is that, if we are interested in VoIP as a driving use > case for this, the amount of time to discover this has to be relatively > short. If it takes 30 seconds, the users in the call would have already > hung up. That requires the connectivity checks to be sent at a rapid > clip. Furthermore, in the case of such a failure, signaling would fail > too in all likelihood (depending where the servers are), which would > require some SIP operations. > > So, the issue is, is it worth it? I have gotten a few complaints about > the complexity introduced by the mid-session checks. Thus, we have three > choices as I see it: > > 1. remove the checks completely > > ICE runs only on setup, to do an initial check. RTCP would, for example, > allow you to detect some of these failure situations mid-call. Recovery > would require re-establishing the call. > > 2. keep the checks > > THe draft stays as is > > 3. Allow for the usage of the checks to be negotiated > > In case a client doesn't want to implement support for the mid-session > checks, we make them optional and allow it to be signaled. > > > I'd prefer NOT to do 3, in the interest of avoiding protocol options. > The argument in favor of 1 is primarily one of simplification, and that > you will have to make these connectivity checks really fast in order to > be responsive enough to really recover from a failure, which could be a > problem. > > As I constantly hear these days that "ICE is too complicated", in the > interests of simplification, I'd be game to remove the feature. It could > be added back in as an extension later if needed. > > Comments? > > -Jonathan R. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 09:30:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27846 for ; Thu, 21 Oct 2004 09:30:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdDU-0002gH-V1 for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 09:43:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKco9-0008G1-ED; Thu, 21 Oct 2004 09:16:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcCa-0006W9-JQ for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 08:37:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17535 for ; Thu, 21 Oct 2004 08:37:54 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcP1-0008VD-Fl for mmusic@ietf.org; Thu, 21 Oct 2004 08:50:59 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9LCbgWR003668 for ; Thu, 21 Oct 2004 14:37:43 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 14:37:42 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSJZDRF; Thu, 21 Oct 2004 14:37:39 +0200 Message-ID: <4177AD93.8050400@ericsson.com> Date: Thu, 21 Oct 2004 14:37:39 +0200 X-Sybari-Trust: 0d8acb3a bfd556f1 3389c777 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "mmusic (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 12:37:42.0568 (UTC) FILETIME=[C231DA80:01C4B76A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit In the latest RTSP core draft their is a MUST implement OPTIONS method for an client. I propose that we lower the bar to SHOULD implement OPTIONS and give a motivation as being the main capability negotiation mechanism. Any objections to this proposal? Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 09:47:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29358 for ; Thu, 21 Oct 2004 09:47:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdU8-00036G-Dj for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 10:00:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKd0i-0001T9-MQ; Thu, 21 Oct 2004 09:29:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcnM-0007YM-9G for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 09:15:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25872 for ; Thu, 21 Oct 2004 09:15:54 -0400 (EDT) Received: from webadmin.keyvoice.com ([12.153.69.6] helo=home.ringle.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKczy-00026y-FB for mmusic@ietf.org; Thu, 21 Oct 2004 09:28:59 -0400 Received: by home.ringle.org (Postfix, from userid 501) id B352FB870C; Thu, 21 Oct 2004 09:15:18 -0400 (EDT) From: Jon Ringle To: mmusic@ietf.org Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks Date: Thu, 21 Oct 2004 09:15:17 -0400 User-Agent: KMail/1.5 References: <41765E18.1050900@dynamicsoft.com> In-Reply-To: <41765E18.1050900@dynamicsoft.com> MIME-Version: 1.0 Content-Disposition: inline X-UID: 2469 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200410210915.18122.ml-mmusic@ringle.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ml-mmusic@ringle.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Alternate suggestion inline. On Wednesday 20 October 2004 08:46 am, Jonathan Rosenberg wrote: > Folks, > > One of the big changes in the -02 ICE spec was the addition of > mid-session connectivity checks. These checks served several purposes: > > 1. detection of a network failure that causes an interface to become > unreachable > > 2. in the case of a failure of a nat in the middle of the network, if > the nat recovers, or a backup takes its place, a new binding will get > assigned, and it can be discovered > > > The particular motivating use case for 2 is an enterprise that is > multihomed. It has a NAT on each of its two interfaces to its providers. > The enterprise uses the address prefix provided from provider A, and > advertises reachability to this prefix into provider B. A client within > the enterprise makes a call. The NAT and/or connection to provider A > fails. Routing now causes outbound UDP packets to go over the interface > to provider B. So, outbound UDP packets from the client now go through > this other NAT. It assigns a new binding. With mid-session checks, the > new binding can be learned by the peer, and communications established > using it. > > Now, the trick is that, if we are interested in VoIP as a driving use > case for this, the amount of time to discover this has to be relatively > short. If it takes 30 seconds, the users in the call would have already > hung up. That requires the connectivity checks to be sent at a rapid > clip. Furthermore, in the case of such a failure, signaling would fail > too in all likelihood (depending where the servers are), which would > require some SIP operations. > > So, the issue is, is it worth it? I have gotten a few complaints about > the complexity introduced by the mid-session checks. Thus, we have three > choices as I see it: > > 1. remove the checks completely > > ICE runs only on setup, to do an initial check. RTCP would, for example, > allow you to detect some of these failure situations mid-call. Recovery > would require re-establishing the call. > > 2. keep the checks > > THe draft stays as is > > 3. Allow for the usage of the checks to be negotiated > > In case a client doesn't want to implement support for the mid-session > checks, we make them optional and allow it to be signaled. I offer another suggestion: Remove the STUN mid-call connectivity checks (or keep them to a minimum only to refresh bindings). A timer could be placed based on the reception of RTP packets (since ICE is demuxing STUN/RTP it is in a position to do this). If the timer fires due to no RTP packets received within a specified time (codec dependant), and the session has not been terminated yet, then this endpoint knows that there is a possible problem with the peer endpoint being able to reach this endpoint. This endpoint could then perform STUN connectivity checks. When the peer receives a STUN bind request mid-call, it can then assume that the reason it is receiving a STUN bind request is because it's RTP media is not reaching it's peer. The peer endpoint can then perform it's own connectivity checks again. Jon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 11:28:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13085 for ; Thu, 21 Oct 2004 11:28:01 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKf3e-0005z4-EC for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 11:41:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKekJ-0003sJ-O9; Thu, 21 Oct 2004 11:20:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKeYG-0006XI-4C for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 11:08:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11121 for ; Thu, 21 Oct 2004 11:08:25 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKekj-0005V4-Bj for mmusic@ietf.org; Thu, 21 Oct 2004 11:21:32 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9LF8CfM019513 for ; Thu, 21 Oct 2004 17:08:16 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Oct 2004 17:08:04 +0200 Received: from ericsson.com (RESEARCH-64DE67 [147.214.97.152]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQDTMDR; Thu, 21 Oct 2004 17:08:13 +0200 Message-ID: <4177D0DC.2010103@ericsson.com> Date: Thu, 21 Oct 2004 17:08:12 +0200 X-Sybari-Trust: ffc2134f bfd556f1 3389c777 00000139 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Euchner Martin References: <8C878B55C96F924389908D4A7384842A03A02B9B@mchh2c7e.mchh.siemens.de> In-Reply-To: <8C878B55C96F924389908D4A7384842A03A02B9B@mchh2c7e.mchh.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Oct 2004 15:08:04.0603 (UTC) FILETIME=[C3BF24B0:01C4B77F] X-Spam-Score: 1.2 (+) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 1.2 (+) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: 7bit Hi again Martin, Yes, we think we are almost in complete agreement now. Final(?) thoughts below: Euchner Martin wrote: > Mats, > > Once again many thanks for your good answers that indeed clarify a lot > of the misunderstandings. > > To quickly summarize: I believe that we are already very close in our > views; I don't see any real disagreement. > > However, I see some further related issues on how the answerer has > implemented its system. Originally, I had the "insecure implementation" > in mind, yet it was not immediately apparent to me that this is the main > cause of the problem. I would at least ask for your confirmation, if > that is correct; see the longer added statements with the counter > example in the middle of the email. > > Cherio > > Martin. > > > MEU:> Ok this confirms that kmtext "negotiates" a key management > >protocol family, but does not actually negotiate any particular key > >management capability. I intentionally put negotiate in quotes, since > > > Well, we would e.g. assume that if a shared key is known, that method > would in general be preferred (even if you by chance also know a public > key), and the need to negotiate in that "dimension" would be small. > > Still, we think also that sort of negotiation *could* be done > with a security that is not lower than if just single offers were > allowed, see below. > > > MEU: ok. > > > My only concern in the context of a bidding-down attack is, that the > >bidding-down attack could be accomplished within a spurious hop > > What do you mean by "spurious hop" ? > > MEU:> sorry for not having explained the attack scenario. It is exactly > the case that you showed in 1. and in 2, where an evil Eve who is not > trusted by the offerer nor the answerer runs a modification/substitution > attack on at least one SDP a-line. > > >somewhere between the originating and terminating end systems, such > >that the attacker replaces a stronger offer by a weaker one of the same > >protocol family. For the bidding-down attack success, the strength of > > Neglecting that we don't understand "spurious hop", we still think > that the attack you describe is of the following form: > > 1. The Initiator makes an offer containing m > 1 MIKEY > alternatives/lines. > > 2. Somehow, along the path, at least one of the m MIKEY offers > get replaced by another (weaker) MIKEY offer that was not in > the original offer. > > Correct? > > MEU:> yes exactly. > > If so, let's call the weak MIKEY variant "MIKEY-X", be it password > based or otherwise. > > Now we need to ask, how could it be that the inserted MIKEY-X offer > gets accepted as authentic by the Responder? > > > As we see it, that would only be possible if either: > > A) the MIKEY-X offer is a replay of an old offer (which would normally > be taken care of by MIKEY-X replay protection), or, > >MEU: actually I had in mind just this case as I did not assume case B >to happen (so my assumption is also along the lines that MIKEY-X still >provides some meaningful security level, yet it is possibly lower in >security level than any of the current MIKEY protocol variants.) > > B) The MIKEY-X option is so weak in itself that it is possible > to fake MIKEY-X messages without even resorting on replay. > > MEU:> You are right that this case would also exist. > > But if either of these would be possible, there would be > a flaw in that specific MIKEY-X variant, and it really doesn't > matter that there were more than one offer in the original > message: the attacker could fake MIKEY-X offers according to that > (single) MIKEY-X version at any point in time, right? The real > Initiator doesn't even need to be on-line. Thus, you *could* say that > you have a bidding down attack, but that is not *the* real problem. > The problem is more fundamental than that. > > MEU: I tend to agree with that given that Eve somehow must have >substituted actually a replayed MIKEY protocol run. I really cannot >think of any much different attack right now. OK. > > Now if Eve had done so, then the answerer could detect this attack, by >verification that the integrity of >each< offered MIKEY protocol holds >valid. For the replayed option, the verification would fail (e.g. >re-used nonce or expired timestamp etc). > > So I agree with you that the answerer has a real chance to detect a >bidding-down attack. This is good and removes my original concern. OK. > > New concern: Unfortunately, this comes at a high price; namely the >answerer MUST implement all MIKEY protocol variants even those that >MIKEY calls just optional to implement such as MIKEY-DHSIGN, in order >to be able to protect against bidding-down attacks. Right? No. The bidding down attack will only be *detected* if the Responder supports the variant that was inserted (MIKEY-X in the above case). If the Responder does not even support MIKEY-X, the *substitution* will not be detected, but OTHO you cannot then even talk of "bidding down" in this case, since it's simply not possible to fool the Responder into using something he doesn't even support. > > I cannot fully believe this to be true right now, as this questions the choice of making certain MIKEY protocols optional altogether. > > Why is it so? In summary, you are right in the sense that the modification cannot be *detected* unless all variants are supported, but OTOH, you cannot "bid down" to something that is not implemented. For instance, if you don't support MIKEY-DH, how can I fool you into using it? > > So the answerer MUST first verify all received MIKEY protocol offers, >and just after that actually would decide which option to choose >(authenticate first then policy decide). > > In fact, doing it the other way round (i.e. 1st make protocol choice then verify that the choice is authentic) would be insecure, even if the choice is not the replayed protocol offer! See counter example: This is in very true: you can in general not make secure decisions based on (possibly) faked information, agreed. [snip] We took the liberty of deleting your example of the above, we generally agree with you. Best, /Mats and MIKEY team _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 13:23:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25255 for ; Thu, 21 Oct 2004 13:23:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKgrT-0000P8-Fg for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 13:36:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgbT-0000gl-Vd; Thu, 21 Oct 2004 13:19:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgSB-0003cV-1l for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 13:10:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23975 for ; Thu, 21 Oct 2004 13:10:15 -0400 (EDT) Received: from web53706.mail.yahoo.com ([206.190.37.27]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKgeo-000065-RA for mmusic@ietf.org; Thu, 21 Oct 2004 13:23:24 -0400 Message-ID: <20041021170947.25889.qmail@web53706.mail.yahoo.com> Received: from [202.4.189.74] by web53706.mail.yahoo.com via HTTP; Thu, 21 Oct 2004 10:09:47 PDT Date: Thu, 21 Oct 2004 10:09:47 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request To: Magnus Westerlund , "mmusic \(E-mail\)" In-Reply-To: <4177AD93.8050400@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Magnus, Actually there is some contradiction in section 11.1 and D.1 (minimal client implementation). 11.1 says that OPTIONS is must for client but according to D.1 this is not MUST probably this is what you are pointing at. If so then shouldn't the server support for OPTIONS be also changed from MUST to should in D.2 ? sunil bhargo --- Magnus Westerlund wrote: > In the latest RTSP core draft their is a MUST > implement OPTIONS method > for an client. I propose that we lower the bar to > SHOULD implement > OPTIONS and give a motivation as being the main > capability negotiation > mechanism. > > Any objections to this proposal? > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 15:19:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09181 for ; Thu, 21 Oct 2004 15:19:39 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKig2-0003ze-7M for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 15:32:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiOj-0000pf-5y; Thu, 21 Oct 2004 15:14:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKi8c-0001C6-2s for mmusic@megatron.ietf.org; Thu, 21 Oct 2004 14:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06046 for ; Thu, 21 Oct 2004 14:58:12 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiLH-0003PW-AC for mmusic@ietf.org; Thu, 21 Oct 2004 15:11:20 -0400 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id i9LIw9fO024424; Thu, 21 Oct 2004 20:58:09 +0200 Received: from moody.mchh.siemens.de (moody.mchh.siemens.de [139.21.205.85]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id i9LIw9YO018562; Thu, 21 Oct 2004 20:58:09 +0200 Received: from mchh275e.mchh.siemens.de (mchh275e.mchh.siemens.de [139.21.200.61]) by moody.mchh.siemens.de (8.12.6/8.12.6) with ESMTP id i9LIw817021857; Thu, 21 Oct 2004 20:58:08 +0200 Received: by mchh275e.mchh.siemens.de with Internet Mail Service (5.5.2657.72) id ; Thu, 21 Oct 2004 20:58:07 +0200 Message-ID: <8C878B55C96F924389908D4A7384842A03A02BAE@mchh2c7e.mchh.siemens.de> From: Euchner Martin To: =?ISO-8859-1?Q?=27Mats_N=E4slund=27?= , Euchner Martin Date: Thu, 21 Oct 2004 20:58:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] RE: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Hello Mats and MIKEY gang, Thanks once more for the helpful responses. I've added inline below my comments to the exchange before. I believe we are getting very close now. So to summarize the discussion and where we stand: 1) There is nothing wrong with MIKEY; all known MIKEY protocol variants provide sufficient and good security to protect against manipulation attacks on the SDP key management phase. 2) I don't see kmgtext-11 protocol being flawed either. 3) I'm a bit concerned that the overall security very much depends on a correct implementation of the responder, in particular the right processing order of the steps. My concern is fostered by the feeling that while for security experts, the correct and secure processing order is obvious, I'm not so certain, if it is also that obvious for non-security experts; especially, since I could not find any advice/or caution anywhere in the kmgtext document. So I would like to ask the WG: Do you see a need to add some advice or caution (possibly in the security consideration section) that explains what to do on the responder side? I would highly appreciate to see such a text as some generally useful non-obvious but important detail. 4) We clarified that the KMID is on the key management protocol level, the current KMID scheme does not reflect the MIKEY protocol variant level. 5) We are in agreement that the bidding-down attack can be mitigated at the responder as long as the responder implements all possible MIKEY protocol options, even those that are not of interest to the responder, and of course that the responder verifies each received option to detect if it is an injection/replacement/replay etc. 6) We are also in agreement that we are concerned about bidding-down attacks on the protocol level, but not on the algorithm/parameter level; the latter would assume a very insecure MIKEY protocol anyhow; we can de-scope this easily from our discussion. 7) I believe that we are further in agreement that the current mechanism operating on a key management protocol level and the procedures are secure but come at a high price (number of implemented options, performance). I am clearly concerned about the consequences, namely that the existing mechanism is very costly. Do we really want this?? Or can we try to improve? 8) Where could we improve it? Which bidding-down attacks are worth it? This is a requirements question: I would like to see a) better (i.e. cheaper) yet equally secure protection mechanism in place that quickly detects a maliciously injected/substituted MIKEY protocol option that the responder has not implemented and/or doesn't want to support. b) Possibility for the responder to quickly decide without full verification of all offers not to consider further a particular offer. c) The responder being able to quickly sort out attacks from a bidding-down attempt. So in essence I believe I'm requiring that the MIKEY protocol identifier becomes an authenticated one. Imagine an example with a PKI enabled environment where MIKEY-DHSIGN or MIKEY-PK are possible but MIKEY-PS is also available and implemented and where the security policy of the responder would always prefer a PKI option unless such one is not offered. In this example, the responder upon reception of (DHSIGN, PK, PS) offer would just decide which of both DHSIGN or PK to take, and then verify the offered and chosen MIKEY protocol string. The responder does not need to verify the other offered MIKEY strings. So there is only one MIKEY instantiation instead of three. Wouldn't that be worth it? In the example above where the responder receives an attacked offer of (DHSIGN, PK; PW) and PW is not supported or implemented, the PW option can instantly be sorted out and would not be processed any further. This would even improve resistance against certain DoS attacks, but that's a different issue not of my concern here. 9) I wouldn't have argued so long, without offering a solution that (hopefully) would work roughly as follows: - each offered MIKEY protocol option is identified by a specific KMID. One for MIKEY-PS, a different KMID for MIKEY-DH etc - we take advantage of the fact that MIKEY strongly integrity protects the list of protocol IDs end-to-end; so the KMIDs are indeed authenticated. - The responder can detect a) an injected additional KMID offer or b) an offer that is replaced by new KMID (and string) which is not supported simply as the KMID doesn't show up within the protected protocol list. Thus, the responder does not require implementation of all options to thwart bidding-down attacks. The responder can reject offers that he/she hasn't implemented or for some policy reason, doesn't want to support. 10) Isn't it obvious that allocation of a few KMIDs basically and a few checks upon them by the responder is a much cheaper mechanism to satisfy above requirement than brute-force verification of each and every received option by the receiver? I put this proposal forward to discussion. Cheers Martin. Hi again Martin, Yes, we think we are almost in complete agreement now. Final(?) thoughts below: MEU:> yes I think so too, nearly. So let's clear up the remaining issue. > > New concern: Unfortunately, this comes at a high price; namely the >answerer MUST implement all MIKEY protocol variants even those that >MIKEY calls just optional to implement such as MIKEY-DHSIGN, in order >to be able to protect against bidding-down attacks. Right? No. The bidding down attack will only be *detected* if the Responder supports the variant that was inserted (MIKEY-X in the above case). MEU> yes under the condition that the responder has implemented the inserted option and first checks validity of the offer, before deciding further. On the latter we have clearly agreement that not doing so would be highly insecure. If the Responder does not even support MIKEY-X, the *substitution* will not be detected, but OTHO you cannot then even talk of "bidding down" in this case, since it's simply not possible to fool the Responder into using something he doesn't even support. In summary, you are right in the sense that the modification cannot be *detected* unless all variants are supported, but OTOH, you cannot "bid down" to something that is not implemented. For instance, if you don't support MIKEY-DH, how can I fool you into using it? MEU:>ok, as above. However, bad implementation of the processing order in the responder could indeed lead to a successful bidding-down attack, where the attacker forces the responder to choose an implemented option of lower security level (than without attack), where the responder actually hasn't implemented even the injected option. > > So the answerer MUST first verify all received MIKEY protocol offers, >and just after that actually would decide which option to choose >(authenticate first then policy decide). > > In fact, doing it the other way round (i.e. 1st make protocol choice then verify that the choice is authentic) would be insecure, even if the choice is not the replayed protocol offer! See counter example: This is in very true: you can in general not make secure decisions based on (possibly) faked information, agreed. MEU: ok we are in agreement. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 21 20:07:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07418 for ; Thu, 21 Oct 2004 20:07:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKnAG-0004Vn-Ly for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 20:20:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKl6S-0005D7-58; Thu, 21 Oct 2004 18:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKj5x-0001sL-Te; Thu, 21 Oct 2004 15:59:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14009; Thu, 21 Oct 2004 15:59:31 -0400 (EDT) Message-Id: <200410211959.PAA14009@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 21 Oct 2004 15:59:31 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rtsp-announce-00.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --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 : RTSP Announce Method Author(s) : T. Zeng, G. Sherwood Filename : draft-ietf-mmusic-rtsp-announce-00.txt Pages : 0 Date : 2004-10-20 This memo describes an extension RTSP request, ANNOUNCE, which extends the core RTSP protocol [RTSP_NEW] to allow one end to push to the other end various types of information by RTSP means. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rtsp-announce-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rtsp-announce-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rtsp-announce-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: <2004-10-21154726.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rtsp-announce-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rtsp-announce-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-21154726.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 21 21:35:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25733 for ; Thu, 21 Oct 2004 21:35:17 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoXc-0001OQ-Kv for mmusic-web-archive@ietf.org; Thu, 21 Oct 2004 21:48:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKnos-0003iY-1Q; Thu, 21 Oct 2004 21:02:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlDp-0003z9-Fo; Thu, 21 Oct 2004 18:15:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12914; Thu, 21 Oct 2004 18:15:46 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKlQW-0005Ds-9e; Thu, 21 Oct 2004 18:28:56 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9LMFd1U003946; Thu, 21 Oct 2004 15:15:39 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I5Y00ILWDPAI0@gateway2.EECS.Berkeley.EDU>; Thu, 21 Oct 2004 14:15:11 -0700 (PDT) Date: Thu, 21 Oct 2004 15:15:38 -0700 From: lazzaro Subject: Re: [MMUSIC] maxptime In-reply-to: <4177691F.9090800@ericsson.com> To: Magnus Westerlund Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <75B73F9E-22BF-11D9-A6E7-00039372C384@eecs.berkeley.edu> <4177691F.9090800@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 Content-Transfer-Encoding: 7BIT Cc: avt@ietf.org, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7BIT On Oct 21, 2004, at 12:45 AM, Magnus Westerlund wrote: > Hi John, Hi Magnus! There are a few separable issues here, let's take them one by one ... CC'd to AVT since these issues cross boundaries ... > I think the usage of maxptime=0 may be a bit problematic. A > interpretation is that no audio can be included in the packet, as no > audio duration is allowed. > > I see that you have made another interpretation in the MIDI draft > (draft-ietf-avt-rtp-midi-format-06): > > "0 ms is a reasonable media time value for MIDI packets. In a packet > with a 0 ms media time, all commands execute at the instant coded by > the > packet timestamp. Prohibitions in [13] against 0 ms ptime values are > not relevant for MIDI streams, and may be ignored." > > An RTP timestamp tick is strictly not an instant, it has a duration > equal to 1/(RTP timestamp rate). > However these is my interpretation. Here's the underlying motivation for the choice I made. Imagine playing the piano. Play three notes simultaneously. In MIDI, this corresponds to three separate NoteOn commands. In RTP MIDI, each has a timestamp, expressed in RTP timestamp units. It's really important to the sonic integrity of the piece to code that the notes happen simultaneously -- even one RTP tick matters. The reason is, phase effects as the waveforms beat against each other change the timbre. Hand drummers on the list (conga, etc) can attest to this -- the art of creating certain timbres on those types of percussion instruments is based on fine timing of strokes on the drum with the two hands. Standard MIDI Files do in fact code true simultaneity, which is why they can be used in studio work. Musicians go crazy shifting around MIDI notes by tiny amounts inside the DAW to get this sort of stuff right, and SMFs preserve that hard work on export. Pull back from the nanosecond level to the few-millisecond level, and we move from timbre distortion to timing sloppiness. MIDI as transmitted on a MIDI 1.0 DIN cable suffers from this: at 300 microseconds/command, playing full chords with both hands creates timing slews you can hear. Part of the motivation to move off of MIDI DIN cable technology is to make instrument controllers that don't suffer this timing problem. You might ask -- why can't just put all simultaneous notes in the same packet, and use something other than RTP timestamps to denote intra-packet timing? To understand the answer, you need to understand that a core use of RTP MIDI is on "media LANs" -- a stage or studio situation that may consist of two nodes -- piano controller and laptop -- connected by an Ethernet cable as the Layer 2 for RTP MIDI. These folks want absolute lowest latency -- so, they don't want their piano controller to wait around after the first MIDI command to see if a second command that is "simultaneous" is happening soon. Instead, they want the piano to take each command, put it in its own RTP packet, and send it off. So, they want the ability to send two RTP packets in a row, each coding one MIDI command, each with the same RTP timestamp. To do this, they need the RTP timestamp semantics that say an RTP MIDI packet can have 0 ms media time. Some instrument makers use Ethernet today. They use their own UDP solutions (some use OSC on top of UDP) and have their own code. They want to add support for RTP MIDI, but RTP MIDI needs to work with their model, which is as I describe it above. I would also not be surprised if the recovery journal semantics failed if we moved to your RTP timestamp interpretation, although I'd have to think about to say for certain. Other things might break too. This is a 4-year-old project now, and the timestamp model is a fundamental assumption that underlies RTP MIDI in subtle ways. So, that's the reply to issue #1. Issue #2: > Is really your intention of using maxptime=0 that for each timestamp > tick there is a command(s), a new packet should be sent? I can > understand using ptime=0 to recommend that you do this behaviour but > using maxptime to enforce the behaviour? Yes. Once again, we're talking about apps in the "media network" world, a laptop and piano keyboard with a point-to-point 2-node Ethernet as the Layer 2 for RTP MIDI. The maxptime=0 parameter says: all packets must either code no MIDI commands, or code one or more MIDI commands with the same timestamp -- and thus, the media time for all packets must be 0 ms. This accommodates receivers (such as, currently, sfront!) that do not implement a receiver buffer of any sort. Instead, sfront grabs a packet, and executes all MIDI commands in the packet simultaneously. It relies on the constant nominal latency of the point-to-point Layer 2, and the constant nominal latency of the keyboard sender, for timing accuracy -- not RTP timestamps, which are ignored. Thus, these receivers can't handle a packet that has a non-zero media time -- all they know is "now". If one is designing receivers exclusively for use on media LANs as live performance instruments (in other words -- a musical instrument synthesizers intended to only be played locally), this "no buffer" model makes perfect sense -- it's how soft synths that are driven by MIDI 1.0 cables work today. Eventually, it would be better if these synths incorporated small configurable buffers to compensate for sub-ms jitter, but the conceptual hurdle to do so would be too great for many synth authors to do. In practice, OS APIs will probably implement those buffers if/when they choose to support RTP MIDI as a media LAN MIDI source. So, we need a way for those soft synths to negotiation (via Offer/Answer) to say "I can only handle 0 ms packets, do not send me any other kind". As an aside, RTP MIDI works fairly well Berkeley/Stanford/Berkeley using the no-buffer sfront -- it doesn't get down to the "hand percussion jitter" I mention above, but with a few coding heuristics it produces a playable instrument when I do loop-back (keyboard in Berkeley, RTP MIDI to Stanford and back, which sfront then turns into audio). Chris Chafe sees jitter under the audio sample rate on his DAT-quality long-distance streaming sessions on occassion! Issue #3 > Especially any that is primarily to handle Offer/Answer, where a > normative > MUST be larger than 0 is present. I think you should consider the > impact on interoperability. Well, the easiest thing to do is invent my own SDP parameter as an RTP MIDI replacement for maxptime -- this skirts the compatibility issue. But as I explained above, I think we have a legitimate need for the negotiating functionality. And I think the most elegant thing to do is for maxptime to bend its definition to include 0 ms, just for RTP MIDI, which is why I did it that way ... a compromise would be to put interoperability warning language into the RTP MIDI I-D, but keep the normative text as is. > So lets try to sort this out by answering some questions: > > - How big is the need to be able to specify ptime=0 and maxptime=0, > and what is the effect is the smallest one can use is ptime=1? Hopefully this is answered above. > - Do any implementers of generic SDP parsers have any problems with > ptime or maxptime equals 0? > > - Why does RFC 3264 have a normative MUST against using ptime=0? > > - Any further considerations? These questions seem aimed at others on the list ... however, I should note that I didn't take the route I did on maxptime lightly -- after several years of consensus building with the music technology community, the approach to RTP timing I outline above is the best way I can see to solve their problems. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 03:30:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08330 for ; Fri, 22 Oct 2004 03:30:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKu4v-0008K0-Ep for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 03:43:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtmF-0008SL-FF; Fri, 22 Oct 2004 03:23:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtin-0007Hg-2G for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 03:20:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07244 for ; Fri, 22 Oct 2004 03:20:19 -0400 (EDT) Received: from mail2.cs.tut.fi ([130.230.4.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtvX-00085l-PN for mmusic@ietf.org; Fri, 22 Oct 2004 03:33:32 -0400 Received: from samipelt (samipelt.atm.tut.fi [130.230.52.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.cs.tut.fi (Postfix) with ESMTP id 4816F157931; Fri, 22 Oct 2004 10:19:46 +0300 (EEST) From: "Sami Peltotalo" To: "Mmusic" Date: Fri, 22 Oct 2004 10:21:07 +0300 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-walsh-mmusic-img-envelope-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Hi All, An update to Internet-Draft "The IMG Envelope" is available. http://www.ietf.org/internet-drafts/draft-walsh-mmusic-img-envelope-01.txt All comments are again very welcome. Regards, Sami Peltotalo. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 03:36:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08821 for ; Fri, 22 Oct 2004 03:36:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKuAc-0008QE-JL for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 03:49:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtsx-0002kB-GT; Fri, 22 Oct 2004 03:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtol-0000O2-Ly for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 03:26:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07899 for ; Fri, 22 Oct 2004 03:26:30 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKu1L-0008EM-8J for mmusic@ietf.org; Fri, 22 Oct 2004 03:39:42 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9M7QGWR009539 for ; Fri, 22 Oct 2004 09:26:16 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 09:26:16 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSJ0WMN; Fri, 22 Oct 2004 09:26:16 +0200 Message-ID: <4178B618.80408@ericsson.com> Date: Fri, 22 Oct 2004 09:26:16 +0200 X-Sybari-Trust: cfdf4c5f bfd556f1 394cce6e 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: sunil bhargo Subject: Re: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request References: <20041021170947.25889.qmail@web53706.mail.yahoo.com> In-Reply-To: <20041021170947.25889.qmail@web53706.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 07:26:16.0758 (UTC) FILETIME=[6AFF4560:01C4B808] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Hi, sunil bhargo wrote: > Magnus, > Actually there is some contradiction in section > 11.1 and D.1 (minimal client implementation). 11.1 > says > that OPTIONS is must for client but according to D.1 > this is not MUST probably this is what you are > pointing > at. Yes, it is the MUST in 11.1 that I like to change to a SHOULD or RECOMMENDED. To be consistent that would also mean to make the necessary changes in Appendix D. We have three options on this: A. Make the Implementation of OPTIONS as a requester a MUST. There is no technical reason for this. B. Make an recommendation that clients implement OPTIONS. This due to that it is the main method of learning the methods and feature supported for an resource. However really stripped down clients could skip to implement the method. C. Do not say anything about implementation of OPTIONS at all. I personally do favour B. > If so then shouldn't the server support for > OPTIONS be also changed from MUST to should in D.2 > ? > No, then you loose the possibility to use OPTIONS at all. You need to know that OPTIONS is supported at the server side. Otherwise you can't know for certain that it is possible to learn which methods or features that are supported either globally or for a specific resource. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 05:49:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16351 for ; Fri, 22 Oct 2004 05:49:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwGK-0002F5-LV for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 06:03:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKw2g-00030H-Ok; Fri, 22 Oct 2004 05:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKw1n-0002e9-31 for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 05:48:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16248 for ; Fri, 22 Oct 2004 05:48:04 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKwEX-0002D3-Vu for mmusic@ietf.org; Fri, 22 Oct 2004 06:01:19 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9M9m1318328; Fri, 22 Oct 2004 12:48:01 +0300 (EET DST) X-Scanned: Fri, 22 Oct 2004 12:47:37 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i9M9lbqU002085; Fri, 22 Oct 2004 12:47:37 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Li2Mly; Fri, 22 Oct 2004 12:47:08 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9M9l3S12557; Fri, 22 Oct 2004 12:47:03 +0300 (EET DST) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 12:46:58 +0300 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 22 Oct 2004 12:46:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] draft-walsh-mmusic-img-envelope-01 Date: Fri, 22 Oct 2004 12:46:58 +0300 Message-ID: Thread-Topic: [MMUSIC] draft-walsh-mmusic-img-envelope-01 Thread-Index: AcS4DnrhDaxxcLytSq2fsR5Lkv+RawACV0Mw To: X-OriginalArrivalTime: 22 Oct 2004 09:46:59.0048 (UTC) FILETIME=[12FE7E80:01C4B81C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: sami.peltotalo@tut.fi X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable The (sorry: long overdue) updated version of the IMG envelope deals with = embedding of metadata fragments in a simple way which is also backwards = compatible with the existing referencing approach. It also goes a long = way in explaining the usage of IMG envelopes and provides the textual = (XML) instance of the envelope. The greatest omission is a description of which IMG requirements = (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-07.txt) = are addressed by the IMG envelope and the extent to which they are = fulfilled. Anyone interested may wish to have a look at the 3GPP equivalent = (ftp://ftp.3gpp.org/TSG_SA/WG4_CODEC/Ad-hoc_PSM/Docs/S4-AHP176.zip) = which enables referencing (3GPP has agreed to enable embedding though = the updated schema is not yet in the aggregated specification). Previous = efforts on harmonisation mean that the referencing envelope is currently = identical. Harmonisation on the embedded envelope is realistic so if you = are interested in both IETF and 3GPP please check the schema if you have = not previously got up to speed on this! The authors do not plan to present this I-D in Washington (unfortunately = we 3 are unable to attend). Thus the mailing list (and private emails = for the shy) are the recommended mode review. Cheers, Rod. > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf > Of ext Sami Peltotalo > Sent: Friday, October 22, 2004 10:21 AM > To: Mmusic > Subject: [MMUSIC] draft-walsh-mmusic-img-envelope-01 >=20 >=20 > Hi All, >=20 > An update to Internet-Draft "The IMG Envelope" is available. >=20 > = http://www.ietf.org/internet-drafts/draft-walsh-mmusic-img-envelope-01.tx= t >=20 > All comments are again very welcome. >=20 > Regards, > Sami Peltotalo. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 08:54:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29887 for ; Fri, 22 Oct 2004 08:54:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKz9I-0005XM-MR for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 09:08:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKynZ-0002De-BC; Fri, 22 Oct 2004 08:45:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKygU-0008AU-Qj for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 08:38:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28632 for ; Fri, 22 Oct 2004 08:38:16 -0400 (EDT) Received: from web53708.mail.yahoo.com ([206.190.37.29]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CKytG-00059o-IA for mmusic@ietf.org; Fri, 22 Oct 2004 08:51:32 -0400 Message-ID: <20041022123744.44902.qmail@web53708.mail.yahoo.com> Received: from [202.4.189.74] by web53708.mail.yahoo.com via HTTP; Fri, 22 Oct 2004 05:37:44 PDT Date: Fri, 22 Oct 2004 05:37:44 -0700 (PDT) From: sunil bhargo Subject: Re: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request To: Magnus Westerlund In-Reply-To: <4178B618.80408@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Hi Magnus, B makes sense, would it be better to also recommend that the client uses OPTIONS at the start of the session before any other request so that method capability are known at the start of the session. sunil bhargo --- Magnus Westerlund wrote: > Hi, > > sunil bhargo wrote: > > Magnus, > > Actually there is some contradiction in > section > > 11.1 and D.1 (minimal client implementation). 11.1 > > says > > that OPTIONS is must for client but according to > D.1 > > this is not MUST probably this is what you are > > pointing > > at. > > Yes, it is the MUST in 11.1 that I like to change to > a SHOULD or > RECOMMENDED. To be consistent that would also mean > to make the necessary > changes in Appendix D. > > We have three options on this: > > A. Make the Implementation of OPTIONS as a requester > a MUST. There is no > technical reason for this. > > B. Make an recommendation that clients implement > OPTIONS. This due to > that it is the main method of learning the methods > and feature supported > for an resource. However really stripped down > clients could skip to > implement the method. > > C. Do not say anything about implementation of > OPTIONS at all. > > I personally do favour B. > > > If so then shouldn't the server support for > > > OPTIONS be also changed from MUST to should in > D.2 > > ? > > > > No, then you loose the possibility to use OPTIONS at > all. You need to > know that OPTIONS is supported at the server side. > Otherwise you can't > know for certain that it is possible to learn which > methods or features > that are supported either globally or for a specific > resource. > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@ericsson.com > _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 09:09:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00939 for ; Fri, 22 Oct 2004 09:09:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzMv-0005oh-FP for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 09:22:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz3Q-0008Lf-J7; Fri, 22 Oct 2004 09:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKyxW-0005kB-QZ; Fri, 22 Oct 2004 08:55:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29981; Fri, 22 Oct 2004 08:55:52 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzA9-0005Yh-Fr; Fri, 22 Oct 2004 09:09:08 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MCtefM001501; Fri, 22 Oct 2004 14:55:40 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 14:55:39 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJPCBGYH; Fri, 22 Oct 2004 14:55:39 +0200 Message-ID: <4179034A.2060904@ericsson.com> Date: Fri, 22 Oct 2004 14:55:38 +0200 X-Sybari-Trust: b10e9499 bfd556f1 394cce6e 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: lazzaro Subject: Re: [MMUSIC] maxptime References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 12:55:39.0970 (UTC) FILETIME=[6ECA1A20:01C4B836] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Hi John, Please see below. I also have to point out that I haven't read your drafts during the last year or so. I have only looked at certain specific things in them. lazzaro wrote: > > On Oct 21, 2004, at 12:45 AM, Magnus Westerlund wrote: > > Hi John, > > Hi Magnus! > > There are a few separable issues here, let's take > them one by one ... CC'd to AVT since these issues cross > boundaries ... > > > I think the usage of maxptime=0 may be a bit problematic. A > > interpretation is that no audio can be included in the packet, as no > > audio duration is allowed. > > > > I see that you have made another interpretation in the MIDI draft > > (draft-ietf-avt-rtp-midi-format-06): > > > > "0 ms is a reasonable media time value for MIDI packets. In a packet > > with a 0 ms media time, all commands execute at the instant coded by > > the > > packet timestamp. Prohibitions in [13] against 0 ms ptime values are > > not relevant for MIDI streams, and may be ignored." > > > > An RTP timestamp tick is strictly not an instant, it has a duration > > equal to 1/(RTP timestamp rate). > > However these is my interpretation. > I probably should clarify myself as I have received comments that it seems like I am reinterpreting the timestamp model. The only point I was trying to make is that in a digital domain, compared to the analog an instant is not strictly a precise moment without any duration. Due to the analog to digital conversion the smallest point in time we can express is a single sample (RTP TS tick). That sample represent some duration, equal to 1/(sampling frequency), thus it is not truly instantaneous. To connect to John's example below, about the keyboardist. Even if he strikes the keys simultaneously on a timescale of 1/10000 part of second it is most likely not true when you go to a timescale of 1/10^9 of a second. I will return to this later down. > Here's the underlying motivation for the choice I made. > > Imagine playing the piano. > > Play three notes simultaneously. In MIDI, this corresponds > to three separate NoteOn commands. In RTP MIDI, each > has a timestamp, expressed in RTP timestamp units. > > It's really important to the sonic integrity of the piece to code that > the notes happen simultaneously -- even one RTP tick matters. > The reason is, phase effects as the waveforms beat against each > other change the timbre. Hand drummers on the list (conga, etc) > can attest to this -- the art of creating certain timbres on those > types of percussion instruments is based on fine timing of strokes > on the drum with the two hands. Standard MIDI Files do in fact code > true simultaneity, which is why they can be used in studio work. > Musicians go crazy shifting around MIDI notes by tiny amounts inside > the DAW to get this sort of stuff right, and SMFs preserve that hard > work > on export. > > Pull back from the nanosecond level to the few-millisecond > level, and we move from timbre distortion to timing sloppiness. > MIDI as transmitted on a MIDI 1.0 DIN cable suffers from this: > at 300 microseconds/command, playing full chords with both > hands creates timing slews you can hear. Part of the motivation > to move off of MIDI DIN cable technology is to make instrument > controllers that don't suffer this timing problem. I think I understand this, however the RTP timestamp rate as I understand it for MIDI would be equal to the sample rate for the audio produced? That would mean that it is reasonable to expect that we are working with a sample frequency of for example 48kHz. Or do you needed even higher resolution? > > You might ask -- why can't just put all simultaneous notes > in the same packet, and use something other than RTP timestamps > to denote intra-packet timing? No, I am not questioning this timing model at all. It seems appropriate for RTP based on your description. However one needs to be aware what it means. A MIDI command can't be correctly synchronized with a finer scale then one RTP TS tick. Thus the precision is depending on the timestamp rate. > > To understand the answer, you need to understand that a core > use of RTP MIDI is on "media LANs" -- a stage or studio situation > that may consist of two nodes -- piano controller and laptop -- > connected by an Ethernet cable as the Layer 2 for RTP MIDI. > These folks want absolute lowest latency -- so, they don't want > their piano controller to wait around after the first MIDI command > to see if a second command that is "simultaneous" is happening soon. > Instead, they want the piano to take each command, put it in its own RTP > packet, and send it off. So, they want the ability to send two RTP > packets > in a row, each coding one MIDI command, each with the same > RTP timestamp. To do this, they need the RTP timestamp semantics > that say an RTP MIDI packet can have 0 ms media time. First, I can understand that due to the desire to keep the latency to a minimal even a short buffering is not desirable, however RTP payloads are normal gathered using some type of buffering, either at the encoding step, due to the need to gather sufficient amount of samples to perform the encoding, or at the packetization step to aggregate together sufficient amount of data to get the right efficiency in the transmission. Thus MIDI commands are a bit special. Secondly I don't think we are talking media time really here. The command does not truly have a duration as you say. They takes affect the instant (on a specific sample) indicated by the RTP timestamp. The problem is really about indicating packetization strategies. > > Some instrument makers use Ethernet today. They use their own UDP > solutions (some use OSC on top of UDP) and have their own code. They > want to add support for RTP MIDI, but RTP MIDI needs to work with their > model, which is as I describe it above. > > I would also not be surprised if the recovery journal semantics > failed if we moved to your RTP timestamp interpretation, although > I'd have to think about to say for certain. Other things might break > too. This is a 4-year-old project now, and the timestamp model is > a fundamental assumption that underlies RTP MIDI in subtle ways. > I am not redefining anything. I think we simply have misunderstood each other. > So, that's the reply to issue #1. > > Issue #2: > > > Is really your intention of using maxptime=0 that for each timestamp > > tick there is a command(s), a new packet should be sent? I can > > understand using ptime=0 to recommend that you do this behaviour but > > using maxptime to enforce the behaviour? > > Yes. Once again, we're talking about apps in the "media network" > world, a laptop and piano keyboard with a point-to-point 2-node > Ethernet as the Layer 2 for RTP MIDI. The maxptime=0 parameter > says: all packets must either code no MIDI commands, or code one > or more MIDI commands with the same timestamp -- and thus, the > media time for all packets must be 0 ms. > > This accommodates receivers (such as, currently, sfront!) that do not > implement a receiver buffer of any sort. Instead, sfront grabs a > packet, > and executes all MIDI commands in the packet simultaneously. > It relies on the constant nominal latency of the point-to-point Layer 2, > and the constant nominal latency of the keyboard sender, for timing > accuracy -- not RTP timestamps, which are ignored. Then it is not really RTP you are using. You are ignoring the functionality the timestamp provides to place the different packets correctly on a timescale to combat any transport jitter. As it seems the local stage applications are relying on a consistent transport behavior. > > Thus, these receivers can't handle a packet that has a non-zero media > time -- all they know is "now". > Then they are not RTP aware, a RTP receiver needs to have knowledge about how time flows. > If one is designing receivers exclusively for use on media LANs > as live performance instruments (in other words -- a musical > instrument synthesizers intended to only be played locally), this > "no buffer" model makes perfect sense -- it's how soft synths that > are driven by MIDI 1.0 cables work today. Eventually, it would be > better if these synths incorporated small configurable buffers to > compensate for sub-ms jitter, but the conceptual hurdle to do so > would be too great for many synth authors to do. In practice, > OS APIs will probably implement those buffers if/when they choose > to support RTP MIDI as a media LAN MIDI source. > > So, we need a way for those soft synths to negotiation (via > Offer/Answer) > to say "I can only handle 0 ms packets, do not send me any other > kind". The problem is really to indicate the desired behavior. Which is not really what ptime and maxptime is about. They give the recommend and maximal amount of media duration for a packet. > > Issue #3 > > > Especially any that is primarily to handle Offer/Answer, where a > > normative > > MUST be larger than 0 is present. I think you should consider the > > impact on interoperability. > > Well, the easiest thing to do is invent my own SDP parameter as an > RTP MIDI replacement for maxptime -- this skirts the compatibility > issue. But as I explained above, I think we have a legitimate need > for the negotiating functionality. And I think the most elegant thing > to do is for maxptime to bend its definition to include 0 ms, just for > RTP MIDI, which is why I did it that way ... a compromise would be > to put interoperability warning language into the RTP MIDI I-D, but > keep the normative text as is. The basic problem is that you are using ptime and maxptime way beyond what was ever intended by the authors of these parameters. I am certain of this when it comes to maxptime, as I am the one that defined that one with some help. Therefore I think one needs to look at the different use cases for RTP midi. I think there are several. 1. Local play, where most of RTP's timing model seems to be ignored, as it can't be excepted to buffer in either end of the chain. 2. Transmitting a live session to another point, but in which cases it is acceptable to introduce some small delay. This is done over a network that do not have the jitter behavior necessary to ignore the timestamp. Which means a receiver must follow the timestamp to give the right inter command time spacing. 3. Streaming of midi content. In 1, I think you need something new to indicate the intended behavior of minimal transmission delay and local live play. However I do hope that a sender at least correctly timestamp the RTP packets sent. Thus the RTP receiver can in the future start using the timing model correctly. In 2, I think the usage of ptime and maxptime could be reasonable to instruct a sender to gather 10, 50 or 100 samples or 1, 5, 20 ms of commands into each packet. However if you like to have finer resolution than 1 ms then it is necessary to have a new parameter. In 3, theses parameters are not used at all. The amount of commands in the packets are pre determined for best performance at the receiver. In conclusion I would suggest that you use another MIME parameter than ptime and maxptime to indicate the desired behavior. I also think that the format drafts needs to be more explicit on considerations for the RTP timestamp. What rates are suitable, what are the impact on playback timing. There seems to be a bit on this in the guidelines, but I haven't had time to read it fully. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 09:11:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01176 for ; Fri, 22 Oct 2004 09:11:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzPe-0005sF-Vx for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 09:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz47-0000EK-3u; Fri, 22 Oct 2004 09:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKz0G-0006jh-Qy for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 08:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00227 for ; Fri, 22 Oct 2004 08:58:42 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzCt-0005dg-Nz for mmusic@ietf.org; Fri, 22 Oct 2004 09:11:58 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MCwUfM001972 for ; Fri, 22 Oct 2004 14:58:30 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 14:58:30 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSKCK0G; Fri, 22 Oct 2004 14:58:16 +0200 Message-ID: <417903E8.6020700@ericsson.com> Date: Fri, 22 Oct 2004 14:58:16 +0200 X-Sybari-Trust: e52a3655 bfd556f1 394cce6e 00000139 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: sunil bhargo Subject: Re: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request References: <20041022123744.44902.qmail@web53708.mail.yahoo.com> In-Reply-To: <20041022123744.44902.qmail@web53708.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 12:58:30.0563 (UTC) FILETIME=[D4788730:01C4B836] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Hi, sunil bhargo wrote: > Hi Magnus, > B makes sense, would it be better to also > recommend that the client uses OPTIONS at the start of > the session before any other request so that method > capability are known at the start of the session. I would say that a recommendation depends on what type of session you are going to do. If you are going to do something plan vanilla, then you can simple ensure these things are true with Require header. Also in certain cases, where it is desirable to try to achieve a quick setup, without the extra round trip time, then one can use Require. If one is going to try something very special, not likely to be supported, then the usage of OPTIONS are welcome. This is really a implementation choice for a client. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 10:07:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05899 for ; Fri, 22 Oct 2004 10:07:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0Hq-00071w-1C for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 10:20:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzrq-0001VS-Qk; Fri, 22 Oct 2004 09:54:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzma-0007vQ-E3 for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 09:48:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04271 for ; Fri, 22 Oct 2004 09:48:36 -0400 (EDT) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKzzL-0006dx-GP for mmusic@ietf.org; Fri, 22 Oct 2004 10:01:53 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id 54BAA2FFA137; Fri, 22 Oct 2004 06:48:30 -0700 (PDT) Received: from [10.1.28.2] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id 081512FFA137; Fri, 22 Oct 2004 06:48:26 -0700 (PDT) Message-ID: <41790FC1.30504@acm.org> Date: Fri, 22 Oct 2004 06:48:49 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , IETF MMUSIC WG Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks References: <41765E18.1050900@dynamicsoft.com> <4177A2F9.5080907@acm.org> In-Reply-To: <4177A2F9.5080907@acm.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.implementers.org X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit The reason why I think we should keep the checks, is that it can be useful to choose between different candidates with the same priority. An endpoint can allocate a port on more than one TURN server - on different countries or state. The checks can be used to measure the latency and the packet loss and so dynamically switch to a better route in the middle of a call. Marc Petit-Huguenin wrote: > I would prefer to keep the checks - choice 2. > > Jonathan Rosenberg wrote: > >> Folks, >> >> One of the big changes in the -02 ICE spec was the addition of >> mid-session connectivity checks. These checks served several purposes: >> >> 1. detection of a network failure that causes an interface to become >> unreachable >> >> 2. in the case of a failure of a nat in the middle of the network, if >> the nat recovers, or a backup takes its place, a new binding will get >> assigned, and it can be discovered >> >> >> The particular motivating use case for 2 is an enterprise that is >> multihomed. It has a NAT on each of its two interfaces to its >> providers. The enterprise uses the address prefix provided from >> provider A, and advertises reachability to this prefix into provider >> B. A client within the enterprise makes a call. The NAT and/or >> connection to provider A fails. Routing now causes outbound UDP >> packets to go over the interface to provider B. So, outbound UDP >> packets from the client now go through this other NAT. It assigns a >> new binding. With mid-session checks, the new binding can be learned >> by the peer, and communications established using it. >> >> Now, the trick is that, if we are interested in VoIP as a driving use >> case for this, the amount of time to discover this has to be >> relatively short. If it takes 30 seconds, the users in the call would >> have already hung up. That requires the connectivity checks to be sent >> at a rapid clip. Furthermore, in the case of such a failure, signaling >> would fail too in all likelihood (depending where the servers are), >> which would require some SIP operations. >> >> So, the issue is, is it worth it? I have gotten a few complaints about >> the complexity introduced by the mid-session checks. Thus, we have >> three choices as I see it: >> >> 1. remove the checks completely >> >> ICE runs only on setup, to do an initial check. RTCP would, for >> example, allow you to detect some of these failure situations >> mid-call. Recovery would require re-establishing the call. >> >> 2. keep the checks >> >> THe draft stays as is >> >> 3. Allow for the usage of the checks to be negotiated >> >> In case a client doesn't want to implement support for the mid-session >> checks, we make them optional and allow it to be signaled. >> >> >> I'd prefer NOT to do 3, in the interest of avoiding protocol options. >> The argument in favor of 1 is primarily one of simplification, and >> that you will have to make these connectivity checks really fast in >> order to be responsive enough to really recover from a failure, which >> could be a problem. >> >> As I constantly hear these days that "ICE is too complicated", in the >> interests of simplification, I'd be game to remove the feature. It >> could be added back in as an extension later if needed. >> >> Comments? >> >> -Jonathan R. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 10:08:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06123 for ; Fri, 22 Oct 2004 10:08:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL0IX-00074S-Hq for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 10:21:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzsS-0001mX-Eb; Fri, 22 Oct 2004 09:54:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKzrM-0001CZ-1M for mmusic@megatron.ietf.org; Fri, 22 Oct 2004 09:53:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04559 for ; Fri, 22 Oct 2004 09:53:32 -0400 (EDT) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL047-0006iH-U6 for mmusic@ietf.org; Fri, 22 Oct 2004 10:06:49 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9MDrUfM010959 for ; Fri, 22 Oct 2004 15:53:30 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Oct 2004 15:53:30 +0200 Received: from [147.214.34.59] (research-1fd0e1.ki.sw.ericsson.se [147.214.34.59]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJQD600R; Fri, 22 Oct 2004 15:53:29 +0200 Message-ID: <417910D9.2040005@ericsson.com> Date: Fri, 22 Oct 2004 15:53:29 +0200 X-Sybari-Trust: cec0d8dc bfd556f1 394cce6e 00000979 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: sv, en-us, en MIME-Version: 1.0 To: "Magnus Westerlund (KI/EAB)" Subject: Re: [MMUSIC] RTSP: The normative level for implementation of OPTIONS request References: <417903E8.6020700@ericsson.com> In-Reply-To: <417903E8.6020700@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Oct 2004 13:53:30.0044 (UTC) FILETIME=[831D5FC0:01C4B83E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Magnus Westerlund (KI/EAB) wrote: > Hi, > > sunil bhargo wrote: > > > Hi Magnus, > > B makes sense, would it be better to also > > recommend that the client uses OPTIONS at the start of > > the session before any other request so that method > > capability are known at the start of the session. > > I would say that a recommendation depends on what type of session you > are going to do. If you are going to do something plan vanilla, then you > can simple ensure these things are true with Require header. Also in > certain cases, where it is desirable to try to achieve a quick setup, > without the extra round trip time, then one can use Require. If one is > going to try something very special, not likely to be supported, then > the usage of OPTIONS are welcome. > > This is really a implementation choice for a client. > Clarification: If you need to learn what methods are supported for a resource, then you need to use OPTIONS. Due to the many different needs around capability discovery, I am hesitant to give any recommendation, more than explaining the usability of each method. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Oct 22 18:33:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04302 for ; Fri, 22 Oct 2004 18:33:19 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL8BF-00069r-O0 for mmusic-web-archive@ietf.org; Fri, 22 Oct 2004 18:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL7hi-0005iG-N1; Fri, 22 Oct 2004 18:16:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6my-0002Ai-Uc; Fri, 22 Oct 2004 17:17:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19015; Fri, 22 Oct 2004 17:17:28 -0400 (EDT) Received: from relay0.eecs.berkeley.edu ([169.229.60.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL6zo-0001ZG-Ez; Fri, 22 Oct 2004 17:30:49 -0400 Received: from gateway2.EECS (gateway2.EECS.Berkeley.EDU [169.229.60.39]) by relay0.EECS.Berkeley.EDU (8.13.1/8.12.10) with ESMTP id i9MLHNa9028145; Fri, 22 Oct 2004 14:17:23 -0700 (PDT) Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway2.EECS.Berkeley.EDU (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPSA id <0I6000I6S5O2Y8@gateway2.EECS.Berkeley.EDU>; Fri, 22 Oct 2004 13:16:51 -0700 (PDT) Date: Fri, 22 Oct 2004 14:17:06 -0700 From: lazzaro Subject: Re: [MMUSIC] maxptime In-reply-to: <4179034A.2060904@ericsson.com> To: Magnus Westerlund Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4179034A.2060904@ericsson.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT Cc: avt@ietf.org, mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7BIT On Oct 22, 2004, at 5:55 AM, Magnus Westerlund wrote: > I think I understand this, however the RTP timestamp rate > as I understand it for MIDI would be equal to the sample rate for the > audio produced? Yes -- for best results, the MIDI timestamp resolution should equal the audio sampling rate (44.1, 48, 96, or 192 KHz). > However I do hope that a sender at least correctly timestamp the RTP > packets sent. > Thus the RTP receiver can in the future start using the timing model > correctly. Sender time stamping is a MUST. > In conclusion I would suggest that you use another MIME parameter than > ptime and maxptime to indicate the desired behavior. OK, I'll redo this part of the I-D, and create new MIME parameters to partially convey what the I-D previously coded using ptime and maxptime. Unless a miracle happens, I won't make the Monday deadline with a new I-D pair ... so it will have to wait post-D.C. But I really hope we can make it to Last Call for the two I-Ds by the holidays ... > I also think that the format drafts needs to be more explicit on > considerations for the RTP timestamp. What rates are suitable, what > are the impact on playback timing. There seems to be a bit on this in > the guidelines, but I haven't had time to read it fully. See C.6.3 in the normative I-D. Part of Appendix C.6, the "SDP Interoperability Section", it might be easier to read all of C.6. Also, in the guide I-D, Section 4 discusses sender timing, Section 6 discusses receiver timing. > No, I am not questioning this timing model at all. It seems appropriate > for RTP based on your description. Great -- thinking it over last night, I'm pretty sure that if I was forced to define the media time for a packet with a single MIDI command whose command timestamp equals the RTP timestamp to be 1 RTP timestamp tick long (and not 0 ticks as it is now), the recovery journal would break. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Oct 25 10:44:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01180 for ; Mon, 25 Oct 2004 10:44:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM6Iw-00084i-GS for mmusic-web-archive@ietf.org; Mon, 25 Oct 2004 10:58:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM60l-0002gt-Cc; Mon, 25 Oct 2004 10:39:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5w3-0001Zf-5S for mmusic@megatron.ietf.org; Mon, 25 Oct 2004 10:35:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00313 for ; Mon, 25 Oct 2004 10:34:56 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM69U-0007q1-PL for mmusic@ietf.org; Mon, 25 Oct 2004 10:48:53 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2004 07:43:07 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9PEYNYJ026392; Mon, 25 Oct 2004 07:34:23 -0700 (PDT) Received: from cisco.com ([161.44.79.201]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMN44955; Mon, 25 Oct 2004 10:34:22 -0400 (EDT) Message-ID: <417D0EEE.2010801@cisco.com> Date: Mon, 25 Oct 2004 10:34:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ml-mmusic@ringle.org Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks References: <41765E18.1050900@dynamicsoft.com> <200410210915.18122.ml-mmusic@ringle.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit I agree with the direction Jon is suggesting here, but think it is part of a bigger activity. Without some kind of recovery mechanism, what usually happens is that one or both parties on a call notice that something is wrong with the call - either the media malfunction in some way, or there is some indication that signaling isn't working properly. At that time, the users take remedial action - usually attempting to reestablish the call. I think there should be an analogous process that the endpoints perform on their own, so that the users aren't required to do anything other than tolerate a potential glitch. If this were well specified it wouldn't suffer from the problem that often happen when users do it - such as glare resulting in both getting a busy signal. To achieve this, something needs to monitor the session and identify when there may be a potential problem. A lot of this is monitoring media sessions. How this is done is inherently media specific. For two way RTP based audio media this may, as Jon suggests, only require checking that packets are received periodically, and helping the other end by always sending packets periodically. For one way or idle media this may be a bit more tricky. Sending STUN packets is perhaps one answer, but maybe it is ok to send rtp idle packets (did those get approved?) if it is agreed they can be sent even on a RECVONLY or INACTIVE connection. A similar approach would presumably work for video. Session mode IM will require something different, but the concept is the same. Once there is a hint of a problem, testing and recovery can commence. Part of this is to test the signaling path. This can be any mid-dialog request, but could easily be a reinvite or update that does a new offer/answer. Exactly what kind of offer/answer to do isn't entirely clear. If I think there is a problem, but don't think I am at fault, the "obvious" thing for me to do is to again offer the same SDP I used last. However, that may well solicit an answer the same as last time, and result in absolutely no change in the media. There really needs to be some kind of hint in the reinvite or the accompanying offer that there is a problem to be diagnosed or recovered from. Maybe this would be a Reason header in the reinvite, or something (new preconditions?) in the offer. This should either result in initiating diagnostic actions on one or more media streams, or replacement of resources (ports, relays, etc.) in the path of one or more media streams, or both. There are of course lots of failure modes to consider. In some cases it may be the entire peer UA that has failed, but that has a backup, or it could be a turn server, msrp relay, or NAT that has failed. In any case, the problem extends beyond the scope of what ICE deals with. If this kind of recovery process were supported by every endpoint, then it would be much easier to design and build redundant servers. Paul Jon Ringle wrote: > Alternate suggestion inline. > > On Wednesday 20 October 2004 08:46 am, Jonathan Rosenberg wrote: > >>Folks, >> >>One of the big changes in the -02 ICE spec was the addition of >>mid-session connectivity checks. These checks served several purposes: >> >>1. detection of a network failure that causes an interface to become >>unreachable >> >>2. in the case of a failure of a nat in the middle of the network, if >>the nat recovers, or a backup takes its place, a new binding will get >>assigned, and it can be discovered >> >> >>The particular motivating use case for 2 is an enterprise that is >>multihomed. It has a NAT on each of its two interfaces to its providers. >>The enterprise uses the address prefix provided from provider A, and >>advertises reachability to this prefix into provider B. A client within >>the enterprise makes a call. The NAT and/or connection to provider A >>fails. Routing now causes outbound UDP packets to go over the interface >>to provider B. So, outbound UDP packets from the client now go through >>this other NAT. It assigns a new binding. With mid-session checks, the >>new binding can be learned by the peer, and communications established >>using it. >> >>Now, the trick is that, if we are interested in VoIP as a driving use >>case for this, the amount of time to discover this has to be relatively >>short. If it takes 30 seconds, the users in the call would have already >>hung up. That requires the connectivity checks to be sent at a rapid >>clip. Furthermore, in the case of such a failure, signaling would fail >>too in all likelihood (depending where the servers are), which would >>require some SIP operations. >> >>So, the issue is, is it worth it? I have gotten a few complaints about >>the complexity introduced by the mid-session checks. Thus, we have three >>choices as I see it: >> >>1. remove the checks completely >> >>ICE runs only on setup, to do an initial check. RTCP would, for example, >>allow you to detect some of these failure situations mid-call. Recovery >>would require re-establishing the call. >> >>2. keep the checks >> >>THe draft stays as is >> >>3. Allow for the usage of the checks to be negotiated >> >>In case a client doesn't want to implement support for the mid-session >>checks, we make them optional and allow it to be signaled. > > > I offer another suggestion: > > Remove the STUN mid-call connectivity checks (or keep them to a minimum only > to refresh bindings). A timer could be placed based on the reception of RTP > packets (since ICE is demuxing STUN/RTP it is in a position to do this). If > the timer fires due to no RTP packets received within a specified time (codec > dependant), and the session has not been terminated yet, then this endpoint > knows that there is a possible problem with the peer endpoint being able to > reach this endpoint. This endpoint could then perform STUN connectivity > checks. When the peer receives a STUN bind request mid-call, it can then > assume that the reason it is receiving a STUN bind request is because it's > RTP media is not reaching it's peer. The peer endpoint can then perform it's > own connectivity checks again. > > Jon > > _______________________________________________ > 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-bounces@ietf.org Tue Oct 26 00:13:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09786 for ; Tue, 26 Oct 2004 00:13:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMIwA-0001JL-7b for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 00:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIhM-0008C6-AD; Tue, 26 Oct 2004 00:12:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMIgK-0007iN-U9 for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 00:11:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09497 for ; Tue, 26 Oct 2004 00:11:33 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMItv-0001DC-4T for mmusic@ietf.org; Tue, 26 Oct 2004 00:25:39 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q4AHdj007926; Tue, 26 Oct 2004 00:10:18 -0400 (EDT) Message-ID: <417DCE02.3000904@dynamicsoft.com> Date: Tue, 26 Oct 2004 00:09:38 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Wing Subject: Re: [MMUSIC] ICE Open Issue 5: alt parameter References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Dan, Old message. New data. The new anat draft makes more explicit reference to how it works with ICE, and the new ICE draft makes more explicit reference to how it works with ANAT. -Jonathan R. Dan Wing wrote: > I'd like ICE's "alt" parameter and draft-ietf-mmusic-anat-01.txt to > merge and be one. Or else I'd like to see how -anat- and ICE would > work together -- such an SDP would be difficult to parse at best > (which I believe relates to your issue #1, "v6trans Applicability"). > > -d > > >>-----Original Message----- >>From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]On Behalf >>Of Jonathan Rosenberg >>Sent: Monday, July 26, 2004 12:12 PM >>To: IETF MMUSIC WG >>Subject: [MMUSIC] ICE Open Issue 5: alt parameter >> >> >>At a previous meeting, it was mentioned that 3gpp had defined their own >>SDP parameter called "alt", creating an overlap in the specifications. >>One of the specs needs to change, as a result. However, I am not sure >>what 3gpp spec it was that used "alt", and whether it was still >>proceeding. Indeed, in such a conflict, its not clear who should move >>off the parameter name. I would think that IETF would get priority in >>such cases. >> >>Anyway, the issue is whether we should change the name or not. I'm >>hoping that someone can provide a reference for the 3gpp spec, and/or >>can provide an update on its status. >> >>I'd prefer to not change the name; there are already multiple >>implementations of ICE out there.. >> >>-Jonathan R. >>-- >>Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >>Chief Technology Officer Parsippany, NJ 07054-2711 >>dynamicsoft >>jdrosen@dynamicsoft.com FAX: (973) 952-5050 >>http://www.jdrosen.net PHONE: (973) 952-5000 >>http://www.dynamicsoft.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 01:37:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14846 for ; Tue, 26 Oct 2004 01:37:53 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKFR-0002hY-3R for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 01:51:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK0k-00008w-JN; Tue, 26 Oct 2004 01:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK0V-0008SF-9c for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 01:36:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14827 for ; Tue, 26 Oct 2004 01:36:30 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKE6-0002g2-22 for mmusic@ietf.org; Tue, 26 Oct 2004 01:50:34 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q5a9dj008222; Tue, 26 Oct 2004 01:36:10 -0400 (EDT) Message-ID: <417DE222.4060904@dynamicsoft.com> Date: Tue, 26 Oct 2004 01:35:30 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund References: <4108FB44.5010502@ericsson.com> In-Reply-To: <4108FB44.5010502@ericsson.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Content-Transfer-Encoding: 7bit Cc: "mmusic \(E-mail\)" Subject: [MMUSIC] Re: ICE: Comments on draft-ietf-mmusic-ice-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: 7bit Magnus, Thanks for these great comments, most were incorporated in the -03 draft which you can find at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt inline for more. Magnus Westerlund wrote: > Hi Jonathan, > > I have reviewed your latest ICE proposal and have some comments that I > don't think are in direct relation to the open issues you have presented. > > 1. Section 4. page 8, third paragraph: > "This would > typically be a TURN derived transport address, as it is most likely > to work with unknown non-ICE peers." > > Is this really true. I would say it may be true for a client in a > private network. I don't think it is appropriate to make this statement. > I would say that it is highly dependent on the situation. One may have > public IP addresses, like most of us Swedes, but still need to run ICE > to allow others to get their connection correct. It is indeed problematic. More text has been added to discuss this. There is no cure-all here; the TURN public address is still your best bet, but it won't always work. > > 2. Section 5.1.1, fourth paragraph: > "Each > alternate element conveys a transport address for RTP, one for RTCP, > a STUN username fragment and STUN password. " > > What is the reason to not have separate user and passwords for RTP and > RTCP. They are separate channels, and one needs to ensure that a RTP > channel is not mapped to RTCP. If my understanding of ICE is correct, > the only way to ensure this is to use different usernames. Yes. This was a bug. Usernames and passwords are required for both. The syntax now expresses that, and there is text explaining this. > > 3. Section 5.3.1: Fourth paragraph: > "These protocols work by having the client send, from a specific local > transport address, some kind of message to a server." > > I think it might be clear if one replace "These" with "UNSAF". fixed. > > 4. Section 5.3.2: I am not comfortable with the notion to use the STUN > username to determine that it is STUN request. This will make all other > packets ending up in media protocol. I don't follow this. We've discusssed this issue a bunch. The resolution proposed in this draft is that the transport address first listen for STUN, and then once an RTP packet is received, it switches to RTP. > > 5. Section 5.3.2: page 14: > "The username fragment MUST be globally unique, so that no other host > will select a username with the same value." > > My question is how you ensure this. You haven't specified a mechanism to > ensure that all clients will produce globally unique user names. I think > it is clear that one can produce randomly selected usernames that are > extremely likely to be unique, however to guarantee it seems impossible. A proposed algorithm is provided, and the requirements say it needs to be unique with high probability. > > 6. Section 5.3.3: Page 15, > "If a user is a telecommuter, and therefore connected to their > corporate network and a local home network, they may prefer their > voice traffic to be routed over the VPN in order to keep it on the > local network when communicating within the enterprise, but use the > local network when communicating with users outside of the > enterprise." > > I think the "local" on third line from the end, should be "corporate" > instead. fixed. > > 7. Congestion control: > I think we will need to work out how congestion control should be > handled. In fact I think the initial full mesh STUN check can actually > be sufficient to force some low bit-rate networks into congestion. For > example, if I would connect my laptop with all its interfaces, and get > all sorts of different IP address that I could. I would think I would > end up with 4*4=16 different sourceable interfaces, and that is without > using any UNSAF mechanism, only the two IP versions and VPNs. Point is > that a peer can easily have around 10 announce addresses. If the other > peer then are going to try them in parallel and totally ignores to limit > the request rate, all 10 STUN request could go in a very short time. > This could easily congest the network, if the interface used is for > example a GPRS link, or something similar low bit-rate. > > I do also agree with your later concerns over the timers. I think there > is need to figure out how to ensure that this scales and does not cause > congestion. Both in the simple case of the retry timer, and the quick > recovery method. The timers have mostly been removed; there are no mid-session checks. However, there is still an initial burst of connectivity checks. This seems like it would be very hard to do otherwise. We haven't sent anything on the network yet, so we don't know its transport characteristics to do any congestion control. If we try a slow exponential ramp up, it has a huge, and IMHO unacceptable impact on call setup. As such, I think we should leave it as is. > > 8. Section 5.3.4, page 19: What is FSM? You don't spell it out. Finite State Machine. Now expanded. > > 9. Section 5.3.4, Figure 3: > In the error/set retry timer transition from HANDSHAKING to BAD, isn't > the most likely case, that the giveup timer expires? yes > > 10. Section 5.3.4: page 20, second paragraph: Have you forgotten to > consider packet loss. I would think that packet loss would be likely > reason for the failure. yes, though it would have to be over an extended duration - 9s for the stun transaction to timeout. > > 11. Section 5.3.4: page 20, last sentence: Do you really intended the > refresh timer to be 1 second. That seems all to frequent to keep the > bindings alive, and ensuring that connectivity. This timer is gone. > > 12. Section 5.3.4: page 21, first paragraph: I think there is some need > to some consideration period before switching from Good to BAD. With the > current proposal it seems this will happen on the first packet loss the > STUN traffic encounters. I think it needs to be a bit more robust. I > think one can also to this state consider to take input from the > transport protocol sending media over the address combination. This transition is gone now. > > 13. Section 5.3.5, "Assuming the USERNAME is valid, the client MUST > generate a STUN response per RFC 3489." > > Isn't a valid password also required? yes. Thi s paragraph has been reworded. > > 14. Section 6.1: last sentence: > "However, once one of the clients begins receiving media > on its STUN derived address, it can deallocate its TURN resources." > > Is the above really a positive thing in ICE. If a peer has announced its > TURN address, shouldn't it keep it around. As I understand it can't be > deallocated by the other peer, so it will keep trying it. So the turn > address would always be in BAD state. Also having it around provides > fail over possibilities. The spec says you SHOULD keep them, but often there is no need. The case yo are worried about won't happen. They can only be de-allocated when a higher priority transport was contacted and used. Unless you do re-invites in the sip case, you won't ever receive packets on them. > > 15. section 9: I think the SDP attribute name could be better selected. > I don't think "alt" is really a good name for ICE address elements. Even > a=ice would seem better. It is now a=candidate. > > 16. Section 9. The syntax for the attribute seems broken in two ways: > > There is a missing separator between the RTP and RTCP address, I think > it should read: > unicast-address SP port [SP unicast-address SP port] > > Secondly the syntax element: > derived-from = ":" / id > > is not used. fixed. > > 17. Section 9: > "If the ICE message indicates an RTCP address and port that are not > one higher than that of the RTP, the SDP RTCP attribute [2] MUST be > used to convey them." > > Shouldn't this include the word "default" and read like this: > > If the ICE message indicates an default RTCP address and port that are > not one higher than that of the RTP, the SDP RTCP attribute [2] MUST be > used to convey them. I don't think default is needed; there is no default defined in ICE. > > > 18. Section 9. In regards to my above comment number 2. I think the > attribute should clear separate RTP and RTCP addresses and allow for > individual username and passwords. done. > > 19. Reference 12, need to include the standard number STD 64. xml2rfc does what it does. I can't fix this. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 01:40:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15054 for ; Tue, 26 Oct 2004 01:40:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKI6-0002jt-Io for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 01:54:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK1e-0000IL-3I; Tue, 26 Oct 2004 01:37:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK0i-00008v-9Y for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 01:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14833 for ; Tue, 26 Oct 2004 01:36:43 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKEJ-0002gM-7V for mmusic@ietf.org; Tue, 26 Oct 2004 01:50:47 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q5aXdj008228; Tue, 26 Oct 2004 01:36:33 -0400 (EDT) Message-ID: <417DE23A.1000300@dynamicsoft.com> Date: Tue, 26 Oct 2004 01:35:54 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ml-mmusic@ringle.org Subject: Re: [MMUSIC] Confusion regarding ICE username fragment References: <200410191646.14493.ml-mmusic@ringle.org> In-Reply-To: <200410191646.14493.ml-mmusic@ringle.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Jon, Good question. Basically, this was a bug in ICE. Each local transport address has to have its own username and password. Now, in -03, each local transport address is either used in the initiate/accept mesage, or else is associated with a single derived transport address. This means that if I have a single local interface and can use TURN and STUN unilateral allocations, I'll bind to *three* local interfaces. One of them gets sent directly to the peer. One is used for the STUN allocations. One is used for the TURN allocations. A stun server is set to run locally on all three sockets, and each of the three has a unique username/password. If you don't do this, you run into a nasty problem which is there is no way to reliably know that your peer has suceeded in its connectivity checks. That is needed to allow you to turn off the stun server and accept only media packets. This also simplified the protocol in several places. The drawback (compared to having multiple derived transport addresses from a single local transport address) is that it increases your port usage. I was hesitatnt to go this route at first because of this, but the alternative (not being able to turn off the stun servers) seemed worse based on group consensus on this point. The problem is probably only a big deal in servers like gateways and conference bridges. However, if those do ICE, I wouldn't expect them to do turn or stun, in which case there is no additional cost in terms of socket resources. HTH, Jonathan R. Jon Ringle wrote: > I'm a little confused regarding the use of username fragments in ICE. The > following statement is in draft-ietf-mmusic-ice-02, Section 5.3.2: > > For each local transport address where a STUN server is running, the > client MUST choose a username fragment and a password. The username > fragment created by the client will be concatenated with the fragment > created by its peer. The result will serve as the username provided > by its peer in STUN requests. By creating the username as a > combination of information from each side of a call, it allows a > client to correlate the source of the request with a candidate > transport address. This is discussed further below. > > The username fragment MUST be globally unique, so that no other host > will select a username with the same value. This username fragment > and password will be passed to its peer in an initiate or accept > message. As such, the process described in this section will > associate, with each local transport address, a username fragment and > password. The client also associates this same username fragment and > password with any transport addresses derived from the local > transport address. > > Suppose phone-A has only one local transport address on eth0 and derives a > STUN and TURN address from the eth0 local transport address. From what I read > above, it seems like only a username fragment and password is chosen only for > the eth0 address, and that the derived STUN/TURN addresses use this same > username/password. So, this would result in alt's in SDP in the initiate > message from phone-A to phone-B like this: > > a=alt:1 1.0 : PhoneAeth0user password 172.16.1.102 1234 > a=alt:2 0.8 : PhoneAeth0user password 1.1.1.4 8801 > a=alt:3 0.4 : PhoneAeth0user password 1.1.1.5 3002 > > This seems to go against the examples that are shown in > draft-rosenberg-sipping-nat-scenarios-03, where a separate username fragment > is shown for each local and derived addresses. > > It seems to me that separate username fragments would be needed for each > gathered address for correlation to the candidate table. > > I feel like I am missing a key concept here. Could someone please explain. > > Thanks, > > Jon > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 01:42:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15203 for ; Tue, 26 Oct 2004 01:42:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKK5-0002m7-Pr for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 01:56:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK31-0000TP-Hy; Tue, 26 Oct 2004 01:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMK0q-000092-5S for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 01:36:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14836 for ; Tue, 26 Oct 2004 01:36:51 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKER-0002gS-3g for mmusic@ietf.org; Tue, 26 Oct 2004 01:50:55 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q5aedj008231; Tue, 26 Oct 2004 01:36:40 -0400 (EDT) Message-ID: <417DE241.4020603@dynamicsoft.com> Date: Tue, 26 Oct 2004 01:36:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks References: <41765E18.1050900@dynamicsoft.com> <200410210915.18122.ml-mmusic@ringle.org> <417D0EEE.2010801@cisco.com> In-Reply-To: <417D0EEE.2010801@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Paul, I've come around to this line of thinking too, and this is what is reflected in -03, now available at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt more inline. Paul Kyzivat wrote: > I agree with the direction Jon is suggesting here, but think it is part > of a bigger activity. > > Without some kind of recovery mechanism, what usually happens is that > one or both parties on a call notice that something is wrong with the > call - either the media malfunction in some way, or there is some > indication that signaling isn't working properly. At that time, the > users take remedial action - usually attempting to reestablish the call. > > I think there should be an analogous process that the endpoints perform > on their own, so that the users aren't required to do anything other > than tolerate a potential glitch. If this were well specified it > wouldn't suffer from the problem that often happen when users do it - > such as glare resulting in both getting a busy signal. Right. > > To achieve this, something needs to monitor the session and identify > when there may be a potential problem. A lot of this is monitoring media > sessions. How this is done is inherently media specific. I agree. > > For two way RTP based audio media this may, as Jon suggests, only > require checking that packets are received periodically, and helping the > other end by always sending packets periodically. For one way or idle > media this may be a bit more tricky. Sending STUN packets is perhaps one > answer, but maybe it is ok to send rtp idle packets (did those get > approved?) if it is agreed they can be sent even on a RECVONLY or > INACTIVE connection. If you want to monitor quality, I think RTCP does the job. I don't think you need to send additional packets to generate data to measure. In any case, determining that there has been a quality failure is definitely outside the scope of ICE. In -03, STUN is now only used for the initial checks. mid-call keepalives are handled at the application layer, and there is text on doing that for RTP, which talks about this music-on-hold problem. That is differnt still from detecting failed media to do something about it, which is not addressed at all, beyond a hook I left. The hook that's in there is the treatment of re-invites. If you get one, and nothing has changed, don't do anything. That is, a re-invite in and of itself does not trigger you to restart connectivity checks. But, if the re-invite adds a new candidate address that hasn't been seen before, connecitivyt checks are sent to it. "never seen before" is determined based on boht the transport address AND the username fragment. This means that a client can use a transport address, and then if it thinks there are problems, start up the stun server again, change the username, and do a reinvite to trigger a recheck. > > A similar approach would presumably work for video. Session mode IM will > require something different, but the concept is the same. > > Once there is a hint of a problem, testing and recovery can commence. > Part of this is to test the signaling path. This can be any mid-dialog > request, but could easily be a reinvite or update that does a new > offer/answer. Exactly what kind of offer/answer to do isn't entirely > clear. If I think there is a problem, but don't think I am at fault, the > "obvious" thing for me to do is to again offer the same SDP I used last. > However, that may well solicit an answer the same as last time, and > result in absolutely no change in the media. > > There really needs to be some kind of hint in the reinvite or the > accompanying offer that there is a problem to be diagnosed or recovered > from. Maybe this would be a Reason header in the reinvite, or something > (new preconditions?) in the offer. This should either result in > initiating diagnostic actions on one or more media streams, or > replacement of resources (ports, relays, etc.) in the path of one or > more media streams, or both. Exactly what to do needs futher consideration. I've left just a hook for now. > > There are of course lots of failure modes to consider. In some cases it > may be the entire peer UA that has failed, but that has a backup, or it > could be a turn server, msrp relay, or NAT that has failed. In any case, > the problem extends beyond the scope of what ICE deals with. Yup. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 02:02:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19064 for ; Tue, 26 Oct 2004 02:02:44 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKdU-00034Y-CV for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 02:16:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKL1-0002xn-RE; Tue, 26 Oct 2004 01:57:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKJB-0002OQ-A2 for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 01:55:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15978 for ; Tue, 26 Oct 2004 01:55:48 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKWi-0002xb-6c for mmusic@ietf.org; Tue, 26 Oct 2004 02:09:52 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q5tYdj008296 for ; Tue, 26 Oct 2004 01:55:34 -0400 (EDT) Message-ID: <417DE6AF.6010307@dynamicsoft.com> Date: Tue, 26 Oct 2004 01:54:55 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] summary of resolution of old ICE open issues X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Content-Transfer-Encoding: 7bit Folks, Last August, we had some threads on open issues in ICE. This note summarizes the resolution to each of these in the recently updated -03 document. Issue 1: v6trans applicability > Currently, the ICE spec describes its usage in facilitating the > transition to v6. It points out two possible usages. The first is for > dual-stack hosts, to allow them to advertise addresses for both v4 > and v6, and then use the one which has connectivity. Another one is > for hosts with both v6 native and 6to4 addresses, to detect if native > v6 connectivity exists. > > The open issue is, are these valid and useful usages? Are there other > ones? This isn't so much as an open issue, as it is a "todo", where > the "todo" is to vet this with some folks from v6ops. As such, any > thoughts or inputs here are welcome. I will try to seek some input > while I'm at ietf as well. I havent gotten feedback yet, but I believe the applicability is correct. Issue 2: processing STUN requests before the accept > Consider the following scenario. > > User A sends an ICE initiate message (i.e., SIP INVITE with SDP). It > contains the username fragment contributed by user A. THis arrrives > at the called party, user B. User B sends an ICE accept message > (i.e., a 200 OK with an SDP answer). This contains the username > fragment contributed by user B. User B, in parallel, sends a STUN > request to user A. THat request has a username, and the username is > the concatenation of the two username fragments. Most likely, this > STUN message will beat the accept message (the 200 OK) back to user > A, and be rejected. This case is handled in the spec by having user B > retry (although this is far from obvious and needs to be clarified). > > However, another behavior is possible. Instead of rejecting it, user > A could accept these STUN requests, so long as the first half of the > USERNAME matches the fragment sent by user A in its initiate message. > However, until the accept message is received, user A won't be able > to correlate the source of that stun request with the IP/port/STUN > username fragment/password of its peer, and thus won't be able to > generate its own stun request back to the source of the incoming stun > request. It could cache the source IP/port of the stun request if it > were new, and then gather the information later when the accept > message arrives. However, this increases complexity. > > What do we gain by having the user accept the stun request? Slightly > faster operation, since the called party (user B) may be able to do > its stun connectivity checks even before the 200 OK reaches the > caller. > > So, the open issue is, do folks want to allow user A to accept these > STUN requests before the accept message? > > I'm on the fence somewhat, but probably would vote for no. There seemed to be agreement not to allow this. -03 disallows it. Issue 3: timer settings > Currently, the ICE spec uses a number of timers to control how > frequently a STUN transaction should be re-attempted to verify the > current state. These timers are: > > Refresh timer: While in the GOOD state, when to try again to verify > that its still GOOD? Default: 5s > > Rapid Retry timer: While in the HANDSHAKE state, when to try again > while you wait for your peer to get the accept message and generate > its STUN packets to open permissions? Default: 1s > > Giveup Timer: While in the HANDSHAKE state, when to give up, and > assume the address is no good. Default: 50s > > Retry Timer: while in the BAD state, when to retry to make sure the > address is still BAD. Default: 60s > > > > The timer that needs the most work is the refresh timer. I think that > this should probably be a fraction of the bandwidth of the media > traffic, as a lower bound, just like RTCP. > > The real issue is what to do in failure cases. THe spec currently > says that, if the client should find that its addresses are all in > the BAD state all of a suddent, to push them all into the INIT state > and try to recover. This is meant to deal with a failure of a nat in > the middle of a call that wipes out all of the bindings. Now, whilst > a rapid recovery behavior is good here, it can lead to real problems > if the cause of the failure was NOT a NAT failure, but congestion. In > that case, the response to the congestion loss is to send more > packets - i..e, STUN requests. Thus, some kind of careful retry and > backoff approach is needed. The alternative is to simply not do this. > > > To summarize, the open issues are: > > 1. Are the timers properly set, and should we define a lower bound on > the refresh timer as a fraction of the media bandwidth (I say yes) > > 2. How should we handle the case where all of the addresses enter the > BAD state? Should we support this reconnect mode? This issue is mostly resolved by removal of the mid-session checks. There are still two timers. One controls the gap between STUN transctions in the HANDSHAKE state, which is 50ms (this is NOT the interval between packets - it is the interval between transaction attempts), and a timer for giving up in the handshake state, which is 60s. I think these are fine. Issue 4: TCP applicability > Currently, ICE is mostly worried about media streams over UDP. For > TCP, the problem is less severe, but it does exist. The connectivity > checks are certainly much easier in the TCP case; the ability to set > up a connection represents a valid connectivity check. Its not clear > that STUn should be sent within the connection. The framing and demux > are more complex for TCP than UDP. > > So, the question is, what, if anything, should ICE say about TCP? > > Here is my proposal: > > ICE should be applicable to TCP. In particular, an initiator or > responder can send messages that include alternates for TCP streams. > However, the connectivity checks would not be done using STUN. > Rather, they would be done using something thats media specific. The > initial check is easy - the successful establishment of the > connection. Subsequent checks would be done using something that is > specific to the media. It *could* be stun, but that would be > specified by someone else. > > ICE also specifies that, when a client receives a request, it checks > the source IP/port and considers that a candidate too. I don't think > that behavior really makes sense for TCP. If I receive a connection > setup (i.e., SYN), the resulting connection could be used to send > data to my peer. There is no point in trying to establish a > connection to that source IP/port. > > I think that this works well with comedia, where a passive or actpass > endpoint would list alternates where it can be reached. Once the > connection is established, one cannot anyway open one in the reverse > direction. > > Do folks agree with this proposal? There was mixed opinions on this. Colin made what i felt was the most convincing argument - the industry need is for UDP. Lets solve that first and worry about other things later. Since TCP clearly differs, it would complicate an already complicated protocol even further. So, TCP is not treated in -03. Issue 5: alt parameter > At a previous meeting, it was mentioned that 3gpp had defined their > own SDP parameter called "alt", creating an overlap in the > specifications. One of the specs needs to change, as a result. > However, I am not sure what 3gpp spec it was that used "alt", and > whether it was still proceeding. Indeed, in such a conflict, its not > clear who should move off the parameter name. I would think that IETF > would get priority in such cases. > > Anyway, the issue is whether we should change the name or not. I'm > hoping that someone can provide a reference for the 3gpp spec, and/or > can provide an update on its status. > > I'd prefer to not change the name; there are already multiple > implementations of ICE out there.. Folks wanted to change it for the most part. So, it is now "candidate". This results in a complete break in compatibility with past revs of the draft :( Issue 6: non-STUN connectivity checks > The ICE specification uses STUN, multiplexed within the media stream, > as a form of connectivity check. STUN was chosen originally since, in > addition to providing a check, it also told the client about its > source IP/port as seen by the server. However, in this latest rev of > ICE, the client does not need to learn its IP/port as seen by the > server. The STUN server itself (which is embedded in the peer in the > call) uses the source IP of the STUN request as a new potential media > destination. > > Since the primary feature provided by STUN is no longer required, it > begs the question about what features we do need, and whether STUN > remains the ideal choice. Here are the functions we need from any > connectivity check protocol: > > 1. One side sends a packet to the other which generates an immediate > response > > 2. The response gets back to the originator with high probability, > informing the sender that their original request was received > > 3. The request conveys the source IP/port to the recipient (pretty > much any IP protocol gives us this) > > 4. The request can contain some kind of correlation tag, allowing the > recipient to correlate it as coming from an IP/port advertised in an > SDP offer or answer > > 5. The request can contain a unique identifier, provided by the > client, so it can be sure that the connectivity request was generated > in response to the SDP offer or answer it sent. > > > Clearly, STUN meets these requirements. (1) is met because it > generates a response immediately, (2) is met because STUN is reliable > due to client retransmits, and the response goes back to the source > IP/port, (3) is met easily, (4) is met by using one half of the > USERNAME, and (5) is met by using the other half. > > Now, it is possible for other things to work. In particular, RTP > itself might work: > > (1) We could make use of an immediate RTCP packet sent in response to > an RTP packet. I believe the RTP no-op proposal had a flag for > signaling this. However, RTCP might fail because its sent to a > different IP/port, thus it is not as reliable as STUN. > > (2) We could implement a retransmit strategy ontop of RTP to get > reliability > > (3) is met > > (4) We could use the approach described in > http://www.ietf.org/internet-drafts/draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt, > which allows each side to signal its own half of the SSRC, and then > use one half for the sender correlator > > (5) the other half provides the unique identifier > > > So, what to do here? The options I see are: > > 1. keep it STUN only as specified, 2. allow for multiple mechanisms, > define STUN now, mandate STUN as baseline, and see what happens to > the ssrc demux mechanism, specifying it as an alternative down the > road 3. drop STUN completely, move to RTP with the immediate RTCP > capability and SSRC demux (those would need to be specified within > AVT) > > I am inclined towards (2). I don't like (3) since it will > substantially delay ICE, since it would depend on two mechanisms in > AVT which don't have consensus or clear direction at all, and RTP > doesnt work as well. I think (2) is better than (1) since the > multiplexing of STUN and RTP on the same port is ugly, and it would > be nice to have an out down the road if something better can be > specified. However, we absolutely need a baseline mechanism to have > interoperability, and STUN is that. The current draft removes mid-session connectivity checks. Initial checks are with STUN. Keepalvies are application dependent and done with RTP for RTP applications. There is no way to negotiate something besides stun in this document. I think the need for an alternative is reduced by eliminating the mid-session checks. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 02:04:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20918 for ; Tue, 26 Oct 2004 02:04:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKf7-00036l-DI for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 02:18:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKQY-0005Ca-Q4; Tue, 26 Oct 2004 02:03:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMKO8-0003oq-2S for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 02:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17031 for ; Tue, 26 Oct 2004 02:00:54 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMKbi-00032C-Qo for mmusic@ietf.org; Tue, 26 Oct 2004 02:14:59 -0400 Received: from dynamicsoft.com ([63.113.46.30]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9Q60idj008314 for ; Tue, 26 Oct 2004 02:00:45 -0400 (EDT) Message-ID: <417DE7E5.5020401@dynamicsoft.com> Date: Tue, 26 Oct 2004 02:00:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Subject: [MMUSIC] updated ICE spec X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Folks, I submitted an updated ICE spec yesterday. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt This is a fairly sizeable revision, but much of it is cleanup and addition of further clarification material. A lot was also the "dotting of the i's and crossing of the t's" - completion of IANA registrations, adding diagrams, added explanatory material for call flows, etc. We're currently debating on the list what I think the main issues are - how/when to do the checks - STUN vs. other things, mid-call vs. not. -03 proposes a specific resolution which is consistent I think with some of the recent threads, but we should debate that furhter. Beyond that, I believe we have resolved issues discussed in the past. I've sent a summary of how past open issues were resolved, including responding to several older emails with comments and issues. Please raise any furher issues or comments to the list. Below is a detailed list of diffs from -02 to -03: * changed name of "alt" SDP attribute to "candidate" to avoid conflict with 3gpp attribute of the same name. * removed derived-from SDP attribute, as it is no longer used * changed username SDP attribute component to user-frag * updated XML schema for ICE messages to allow both an IPv4 and IPv6 default. * updated the mapping procedures for ICE to SDP based on the new schema and SDP attribute definitions * noted how performing the address gathering while the user is being alerted, or upon entry of the user into the address book or buddy list, can reduce call setup times * changed TURN and STUN for the purposes of unilateral allocation to SHOULD implement from MUST. Added a long-winded and ranting paragraph on why you really, really to think hard before violating that SHOULD. * allow, at MAY strength, other protocols for creating derived transport addresses * added requirement that password have 128 bits of randomness, and that protocols that do ICE must provide and should use encryption and integrity services. In the case of SIP, made sips usage a SHOULD, SMIME a MAY. Passwords have to differ for each media stream for each session. Usernames are just unique per transport address. * added text describing Pete's scenario where a stun connectivity check is received by the wrong host. * removed mid-session connectivity checks, resulting in adjusted FSM. * STUN service needs to only run until a media packet is received; at that point you can safely switch to media-only operation * added discussion on selecting of default address. Note that TURN-based address from a public relay won't always work. Describe a case where it won't, but still RECOMMEND to use such an address. Add a note on deployment considerations to obviate this, by deploying ICE to communities in whcih joint communications is common (i.e., do the whole enterprise). * adjusted algorithm that runs on receipt of stun requests, simplifying the case where a new candidate address is learned * added pictures to describe turn derived stun addresses * added basic ice model call flow for tutorial purposes * previously, a client obtained local transport addresses and then both used those in its SDP, in addition to deriving perhaps several derived transport addresses from it. No longer. No, there is a single local transport address for each derived transport address, and that local transport address is never advertised in ICE. This turned out to be needed to figure out whether the local stun service could be turned off when an RTP packet is received. Unfortunately it also required me to introduce more terminology to describe. * added a section on application layer keepalive issues. Namely, how to deal with "RTP on hold". This basically replaces the STUN-based connectivity checks * removed concept of sourceable addresses; it fell away with the above change where different local transport addresses are used to obtain each derived transport addresses. * if a gathered transport address is equal to a local transport address, use that local transport address * rewrote security considerations section, which was wrong. Focus on showing how the attacks present in "regular stun" are completely eliminated with ICE * updated and simplified example and filled in textual description * added discussion on handling of re-invites in SIP; the technique allows for connectivity checks to be redone by changing the username fragment. Otherwise, a re-invite where the SDP has not changed has no effect. * filled in details of IANA registration of the candidate parameter. Added registrations of the XML namespace and schema. * fixed incorrect assumptions on 6to4 behavior in IAB considerations * moved TURN to a normative reference * added missing space between RTP and RTCP information in SDP attribute grammar * removed stale derived-from SDP field * RTCP information is optional in ICE now * provided sample algorithm for selecting username fragments * justify the inclusion of the id component of the candidate attribute * specify what to put in the CHANGED-ADDRESS element in a STUN BindingResponse. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 13:22:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25929 for ; Tue, 26 Oct 2004 13:22:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVFW-0008Tb-JX for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 13:36:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUu1-0004Ys-4g; Tue, 26 Oct 2004 13:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUhN-0000Or-Dl for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 13:01:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22935 for ; Tue, 26 Oct 2004 13:01:26 -0400 (EDT) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUv3-0007Vv-Mg for mmusic@ietf.org; Tue, 26 Oct 2004 13:15:38 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp1.clb.oleane.net with ESMTP id i9QH0lsk006599 for ; Tue, 26 Oct 2004 19:00:47 +0200 Message-Id: <200410261700.i9QH0lsk006599@smtp1.clb.oleane.net> From: "peter" To: Date: Tue, 26 Oct 2004 19:00:43 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS7fVSMP/K9sXR+Sz2ORmDprfoYfw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [MMUSIC] WiFi Voice Conference X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1198505982==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de This is a multi-part message in MIME format. --===============1198505982== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C4BB8E.188F2140" This is a multi-part message in MIME format. ------=_NextPart_000_0051_01C4BB8E.188F2140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - What are the market drivers for VoWLAN? - How will VoWLAN systems prioritize and deliver data packets? - What are the planning and engineering issues? - What about security and privacy? At the WiFi Voice Conference to be held in Paris on 10 to 13 May, 2005. distinguished experts and key players in the field will address these questions with detailed and technical explanations. A call for papers is online at: http://www.upperside.fr/wifi05/wifivoice2005intro.htm ------=_NextPart_000_0051_01C4BB8E.188F2140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- What are the market drivers for VoWLAN?
- How will VoWLAN systems prioritize and deliver data packets?
- What are the planning and engineering issues? 
- What about security and privacy? 

At the WiFi Voice Conference to be held in Paris on 10 to 13 = May, 2005. distinguished experts and key players in the field =

will address these questions with detailed and technical explanations.

A call for papers is = online at:

http://www.upperside.fr/wifi05/wifivoice2005intro.htm=

=

 

------=_NextPart_000_0051_01C4BB8E.188F2140-- --===============1198505982== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1198505982==-- From mmusic-bounces@ietf.org Tue Oct 26 13:29:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26527 for ; Tue, 26 Oct 2004 13:29:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMVM8-0000Dp-E5 for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 13:43:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUuB-0004lp-NG; Tue, 26 Oct 2004 13:14:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMUjQ-00014b-5x for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 13:03:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23266 for ; Tue, 26 Oct 2004 13:03:33 -0400 (EDT) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMUx7-0007dZ-BX for mmusic@ietf.org; Tue, 26 Oct 2004 13:17:45 -0400 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp1.clb.oleane.net with ESMTP id i9QH31pe009164 for ; Tue, 26 Oct 2004 19:03:03 +0200 Message-Id: <200410261703.i9QH31pe009164@smtp1.clb.oleane.net> From: "peter" To: Date: Tue, 26 Oct 2004 19:03:00 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS7faXfqw5K3sQ7Tj+MyBBhV+z9Pw== X-Spam-Score: 0.2 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [MMUSIC] WiFi Voice Conference X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0863532978==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. --===============0863532978== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C4BB8E.69C058E0" This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C4BB8E.69C058E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit - What are the market drivers for VoWLAN? - How will VoWLAN systems prioritize and deliver data packets? - What are the planning and engineering issues? - What about security and privacy? At the WiFi Voice Conference to be held in Paris on 10 to 13 May, 2005. distinguished experts and key players in the field will address these questions with detailed and technical explanations. A call for papers is online at: http://www.upperside.fr/wifi05/wifivoice2005intro.htm ------=_NextPart_000_00A5_01C4BB8E.69C058E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

- What are the market drivers for VoWLAN?
- How will VoWLAN systems prioritize and deliver data packets?
- What are the planning and engineering issues? 
- What about security and privacy? 

At the WiFi Voice Conference to be held in Paris on 10 to 13 May, = 2005. distinguished experts

and key players in the field will address these questions with detailed and technical explanations.

A call for papers is = online at:

http://www.upperside.fr/wifi05/wifivoice2005in= tro.htm

=

 

------=_NextPart_000_00A5_01C4BB8E.69C058E0-- --===============0863532978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============0863532978==-- From mmusic-bounces@ietf.org Tue Oct 26 20:32:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13460 for ; Tue, 26 Oct 2004 20:32:14 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbxN-0007NI-52 for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 20:46:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbWw-0001YD-NK; Tue, 26 Oct 2004 20:19:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMZsm-00066W-Te for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 18:33:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12898 for ; Tue, 26 Oct 2004 18:33:33 -0400 (EDT) Received: from [198.66.222.32] (helo=i2telecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMa6A-0005fU-1h for mmusic@ietf.org; Tue, 26 Oct 2004 18:47:49 -0400 Received: from [127.0.0.1] (adsl-64-171-55-1.dsl.snfc21.pacbell.net [64.171.55.1]) (authenticated bits=0) by i2telecom.com (8.13.1/8.12.11) with ESMTP id i9QMX9e1000295; Tue, 26 Oct 2004 22:33:11 GMT Message-ID: <417ED0B4.8050904@i2telecom.com> Date: Tue, 26 Oct 2004 15:33:24 -0700 From: Awais Ali User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] updated ICE spec References: <417DE7E5.5020401@dynamicsoft.com> In-Reply-To: <417DE7E5.5020401@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > * previously, a client obtained local transport addresses and then > both used those in its SDP, in addition to deriving perhaps several > derived transport addresses from it. No longer. No, there is a single > local transport address for each derived transport address, and that > local transport address is never advertised in ICE. This turned out to > be needed to figure out whether the local stun service could be turned > off when an RTP packet is received. Unfortunately it also required me > to introduce more terminology to describe. > If I understand correctly to fulfill this requirement a device that uses both TURN and STUN and is starting an RTP/RTCP session will open six sockets(3 for RTP and 3 for RTCP) and run a STUN server on each of them The advantage of this approach as you mentioned is that the STUN service can be stopped when an RTP packet is received. What will be the downside of keeping the STUN service running? Thanks, Ali Awais _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Oct 26 20:47:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15846 for ; Tue, 26 Oct 2004 20:47:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMcCF-00086A-T9 for mmusic-web-archive@ietf.org; Tue, 26 Oct 2004 21:01:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbi2-0006Bw-6V; Tue, 26 Oct 2004 20:30:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMbNs-0007cd-LQ for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 20:09:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08041 for ; Tue, 26 Oct 2004 20:09:44 -0400 (EDT) Received: from auds951.usa.alcatel.com ([143.209.238.80]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMbba-0005ZW-Pe for mmusic@ietf.org; Tue, 26 Oct 2004 20:23:59 -0400 Received: from srsdmail01.PVNS.COM (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i9R0972Q015315; Tue, 26 Oct 2004 19:09:07 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Confusion regarding ICE username fragment Date: Tue, 26 Oct 2004 17:09:05 -0700 Message-ID: <758B5A159B385447B4F950DE72D7D7AD714D32@srsdmail01.PVNS.COM> Thread-Topic: [MMUSIC] Confusion regarding ICE username fragment Thread-Index: AcS7Hlz4krvvcS9XT4+xuu+jOhAotgAmXYIg From: "Thomas Zeng" To: "Jonathan Rosenberg" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable One comment inlined.=20 > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org] On Behalf Of Jonathan Rosenberg > Sent: Monday, October 25, 2004 10:36 PM > To: ml-mmusic@ringle.org > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Confusion regarding ICE username fragment >=20 > Jon, >=20 > Good question. Basically, this was a bug in ICE. >=20 > Each local transport address has to have its own username and=20 > password.=20 > Now, in -03, each local transport address is either used in=20 > the initiate/accept mesage, or else is associated with a=20 > single derived transport address. This means that if I have a=20 > single local interface and can use TURN and STUN unilateral=20 > allocations, I'll bind to *three* local interfaces. One of=20 > them gets sent directly to the peer. One is used for the STUN=20 > allocations. One is used for the TURN allocations. A stun=20 > server is set to run locally on all three sockets, and each=20 > of the three has a unique username/password. >=20 > If you don't do this, you run into a nasty problem which is=20 > there is no way to reliably know that your peer has suceeded=20 > in its connectivity checks. That is needed to allow you to=20 > turn off the stun server and accept only media packets. This=20 > also simplified the protocol in several places. I'd like to point out that there are use cases for keeping STUN server running on the chosen endpoint (i.e., ) even after connectivity checks have succeeded.=20 For RTSP where media packets flow one way from the RTSP server to its client, it is useful to keep periodic STUN exchanges to keep alive the NAT bindings. It is known in the real world that cerntain NAT bindings will be deleted if there is no traffic going a specific direction (normally from outside in, if I remember correctly). I do agree though the other STUN servers can be closed after the connectivity phase. >=20 > The drawback (compared to having multiple derived transport=20 > addresses from a single local transport address) is that it=20 > increases your port usage. I was hesitatnt to go this route=20 > at first because of this, but the alternative (not being able=20 > to turn off the stun servers) seemed worse based on group=20 > consensus on this point. >=20 > The problem is probably only a big deal in servers like=20 > gateways and conference bridges. However, if those do ICE, I=20 > wouldn't expect them to do turn or stun, in which case there=20 > is no additional cost in terms of socket resources. >=20 > HTH, > Jonathan R. >=20 > Jon Ringle wrote: > > I'm a little confused regarding the use of username=20 > fragments in ICE.=20 > > The following statement is in draft-ietf-mmusic-ice-02,=20 > Section 5.3.2: > >=20 > > For each local transport address where a STUN server is=20 > running, the > > client MUST choose a username fragment and a password. =20 > The username > > fragment created by the client will be concatenated with=20 > the fragment > > created by its peer. The result will serve as the=20 > username provided > > by its peer in STUN requests. By creating the username as a > > combination of information from each side of a call, it allows a > > client to correlate the source of the request with a candidate > > transport address. This is discussed further below. > >=20 > > The username fragment MUST be globally unique, so that=20 > no other host > > will select a username with the same value. This=20 > username fragment > > and password will be passed to its peer in an initiate or accept > > message. As such, the process described in this section will > > associate, with each local transport address, a username=20 > fragment and > > password. The client also associates this same username=20 > fragment and > > password with any transport addresses derived from the local > > transport address. > >=20 > > Suppose phone-A has only one local transport address on eth0 and=20 > > derives a STUN and TURN address from the eth0 local=20 > transport address.=20 > > From what I read above, it seems like only a username fragment and=20 > > password is chosen only for the eth0 address, and that the derived=20 > > STUN/TURN addresses use this same username/password. So, this would=20 > > result in alt's in SDP in the initiate message from phone-A=20 > to phone-B like this: > >=20 > > a=3Dalt:1 1.0 : PhoneAeth0user password 172.16.1.102 1234 > > a=3Dalt:2 0.8 : PhoneAeth0user password 1.1.1.4 8801 > > a=3Dalt:3 0.4 : PhoneAeth0user password 1.1.1.5 3002 > >=20 > > This seems to go against the examples that are shown in=20 > > draft-rosenberg-sipping-nat-scenarios-03, where a separate username=20 > > fragment is shown for each local and derived addresses. > >=20 > > It seems to me that separate username fragments would be needed for=20 > > each gathered address for correlation to the candidate table. > >=20 > > I feel like I am missing a key concept here. Could someone=20 > please explain. > >=20 > > Thanks, > >=20 > > Jon > >=20 > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 > --=20 > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ=20 > 07054-2711 > Cisco Systems > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 03:53:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14336 for ; Wed, 27 Oct 2004 03:53:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMipu-00081D-Pj for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 04:07:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMib5-0002Xw-6U; Wed, 27 Oct 2004 03:51:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMiaG-0002L7-U1 for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 03:51:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14248 for ; Wed, 27 Oct 2004 03:51:02 -0400 (EDT) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMio5-0007zO-E0 for mmusic@ietf.org; Wed, 27 Oct 2004 04:05:22 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9R7p2WR021059 for ; Wed, 27 Oct 2004 09:51:02 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Oct 2004 09:51:02 +0200 Received: from ericsson.com (permit154.er.ki.sw.ericsson.se [147.214.97.154]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJRS9B3K; Wed, 27 Oct 2004 09:51:02 +0200 Message-ID: <417F5366.7020305@ericsson.com> Date: Wed, 27 Oct 2004 09:51:02 +0200 X-Sybari-Trust: 61ad7abb 8cefd49f fd62097d 00000138 From: =?ISO-8859-1?Q?Mats_N=E4slund?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Euchner Martin References: <8C878B55C96F924389908D4A7384842A03A02BAE@mchh2c7e.mchh.siemens.de> In-Reply-To: <8C878B55C96F924389908D4A7384842A03A02BAE@mchh2c7e.mchh.siemens.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Oct 2004 07:51:02.0534 (UTC) FILETIME=[B4A77260:01C4BBF9] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Content-Transfer-Encoding: 7bit Cc: "Karl Norrman \(KI/EAB\)" , "Elisabetta Carrara \(KI/EAB\)" , mmusic@ietf.org, "Jari Arkko \(JO/LMF\)" Subject: [MMUSIC] Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Content-Transfer-Encoding: 7bit Hello Martin, Euchner Martin wrote: > Hello Mats and MIKEY gang, > > Thanks once more for the helpful responses. I've added inline below my > comments to the exchange before. I believe we are getting very close now. Yes it seems that on almost all *detail* we do agree, but we draw different conclusions in the end from these details. You argue there is a bidding-down attack that can/should be mitigated, we argue that is really a side-effect of something else that cannot be solved in the way you propose. In this mail, we will argue again that there is no bidding-down attack issue (the issue is on another level), and furthermore, the countermeasure you suggest is not protecting against it. > > So to summarize the discussion and where we stand: > 1) There is nothing wrong with MIKEY; all known MIKEY protocol variants > provide sufficient and good security to protect against manipulation > attacks on the SDP key management phase. > > 2) I don't see kmgtext-11 protocol being flawed either. > 3) I'm a bit concerned that the overall security very much depends on a > correct implementation of the responder, in particular the right > processing order of the steps. My concern is fostered by the feeling > that while for security experts, the correct and secure processing order > is obvious, I'm not so certain, if it is also that obvious for > non-security experts; especially, since I could not find any advice/or > caution anywhere in the kmgtext document. > > So I would like to ask the WG: > Do you see a need to add some advice or caution (possibly in the > security consideration section) that explains what to do on the > responder side? > > I would highly appreciate to see such a text as some generally useful > non-obvious but important detail. > > 4) We clarified that the KMID is on the key management protocol level, > the current KMID scheme does not reflect the MIKEY protocol variant level. > > 5) We are in agreement that the bidding-down attack can be mitigated at > the responder as long as the responder implements all possible MIKEY > protocol options, even those that are not of interest to the responder, > and of course that the responder verifies each received option to detect > if it is an injection/replacement/replay etc. Here, it is important to be precise. The bidding down can be *detected* if all variants are implmented, but there cannot even be a bidding down to something that is not supported. In either case, it's a non-issue in our opinion. Also, this seems to contradict your concern about the security relying on implementation errors at the Responder: suppose there *is* a really weak variant, which is used to launch the (bidding down) attack. Wouldn't it be better NOT to implement that variant, completely avoiding bidding-down attacks, rather than implementing it just for the sake of *detecting* an attack, and at the same time opening up for an implementation error that by accident actually *accepts* the weak offer? (We argue more below why you cannot detect the attack without implementing all variants.) > > 6) We are also in agreement that we are concerned about bidding-down > attacks on the protocol level, but not on the algorithm/parameter level; > the latter would assume a very insecure MIKEY protocol anyhow; we can > de-scope this easily from our discussion. OK, but why then the concern in 5, which is based on this insecure MIKEY option? > > 7) I believe that we are further in agreement that the current mechanism > operating on a key management protocol level and the procedures are > secure but come at a high price (number of implemented options, > performance). > > I am clearly concerned about the consequences, namely that the existing > mechanism is very costly. Do we really want this?? Or can we try to improve? > Why costly? We have made *provisions* for offering multiple key mgmt protocol, but you don't need to implement more than MIKEY (or some other, single, protocol). We do not mandate multiple protocols, not even all MIKEY variants are mandatory. The mechanism is to be used for those (exceptional) cases where 1. the Initator support more than one protocol, but, 2. has no clue which the Responder supports. > 8) Where could we improve it? Which bidding-down attacks are worth it? > This is a requirements question: > > I would like to see > a) better (i.e. cheaper) yet equally secure protection mechanism in > place that quickly detects a maliciously injected/substituted MIKEY > protocol option that the responder has not implemented and/or doesn't > want to support. Why is it considered a "malicious" act to inject something that the reponder doesn't want to use or perhaps doesn't even support? This is DoS, and could be achieved much simpler, e.g. deleting all key mgt offers, or just garbling them. Given that - we want to open up the possibility for more than one offer, - only the Responder can detect a substitution, and, - he can only verify those options which he/she "understands", we do not see how it can be made simpler, yet still secure (more on that below). > > b) Possibility for the responder to quickly decide without full > verification of all offers not to consider further a particular offer. This is impossible if the arguments above are correct. We have just concluded (or at least we think we can convince you, see below) that to *detect* the attack, you may in the worst case need to implement all variants/offered protocols. From this (if it is correct) it seems to follow that you cannot omit the verification of any single offer, or? > > c) The responder being able to quickly sort out attacks from a > bidding-down attempt. > > So in essence I believe I'm requiring that the MIKEY protocol identifier > becomes an authenticated one. We still argue it doesn't solve the real issue (should such exist). > > Imagine an example with a PKI enabled environment where MIKEY-DHSIGN or > MIKEY-PK are possible but MIKEY-PS is also available and implemented and > where the security policy of the responder would always prefer a PKI > option unless such one is not offered. > > In this example, the responder upon reception of (DHSIGN, PK, PS) offer > would just decide which of both DHSIGN or PK to take, and then verify > the offered and chosen MIKEY protocol string. The responder does not > need to verify the other offered MIKEY strings. So there is only one > MIKEY instantiation instead of three. Wouldn't that be worth it? > > In the example above where the responder receives an attacked offer of > (DHSIGN, PK; PW) and PW is not supported or implemented, the PW option > can instantly be sorted out and would not be processed any further. > Imagine an example with a PKI enabled environment where MIKEY-DHSIGN or MIKEY-PK are possible but MIKEY-PS is also available and implemented and where the security policy of the responder would always prefer a PKI option unless such one is not offered. > > In this example, the responder upon reception of (DHSIGN, PK, PS) offer would just decide which of both DHSIGN or PK to take, and then verify the offered and chosen MIKEY protocol string. The responder does not need to verify the other offered MIKEY strings. So there is only one MIKEY instantiation instead of three. Wouldn't that be worth it? > > In the example above where the responder receives an attacked offer of (DHSIGN, PK; PW) and PW is not supported or implemented, the PW option can instantly be sorted out and would not be processed any further. This Yes, it can also be sorted out by the simple fact that it's not implemented. You seem to suggest a method that can detect certain bidding down attacks in the case when there is a bid-down to something that would anyway never have been chosen by the Responder, becuase he does not support it. We do not consider this an attack. This argument can be turned around, and in doing so, it serves as a counterexample, showing that extending the authenticated info to also include teh "variant" does not help: Suppose the Responder only supports only PW or only PK and that a (PK, PS) offer is replaced (by an attacker) into (PK, PW). Also assume that PK is very strong but PW is weak. The original authenticator in the PK-line would say "MIKEY-PK MIKEY-PS". Now, considering that the attacker managed to fake the PW line, it is likely that it can be made to say "MIKEY-PK MIKEY-PW". Now, a Responder that implements only MIKEY-PK, will detect: "aha, the PS offer has been replaced by a PW offer". But, consider now an attack towards a Responder who only supports PW. In addition to faking the authenticator of the PW part (to say "MIKEY-PK MIKEY-PW", as would be expected), the attacker modifies the PK offer's authenticator to say "MIKEY-PK MIKEY-PW" too. Now, he can't fake the strong signature on this, but he doesn't care since he (correctly) hopes the Responder will not support PK. When the Respoder receives this offer, he will think all is fine. Had he implemented (and used) also the PK variant he would have seen the attack on the PK line, since teh signature wouild be wrong, but now it goes by unnoticed. In summary, to *detect* this attack, the Responder needs to implement (and use) at least one of the "secure" variants. In the worst case, this could be *all* variants (if we are really paranoid). Therefore, adding the the "type" of MIKEY-offer to the authenticated info does not remove the need to verify (possibly) all offers. Note though that (again) we argue that the real issue is an insecure MIKEY variant (PW) that could be used on it's own to cause harm, and therefore these bidding-down attacks are purely artificial examples that do not show the real problem. > would even improve resistance against certain DoS attacks, but that's a > different issue not of my concern here. > > 9) I wouldn't have argued so long, without offering a solution that > (hopefully) would work roughly as follows: > > - each offered MIKEY protocol option is identified by a specific KMID. > One for MIKEY-PS, a different KMID for MIKEY-DH etc > > - we take advantage of the fact that MIKEY strongly integrity protects > the list of protocol IDs end-to-end; so the KMIDs are indeed authenticated. > > - The responder can detect > a) an injected additional KMID offer or > b) an offer that is replaced by new KMID (and string) which is not > supported > simply as the KMID doesn't show up within the protected protocol list. > > Thus, the responder does not require implementation of all options to > thwart bidding-down attacks. The responder can reject offers that he/she > hasn't implemented or for some policy reason, doesn't want to support. > > 10) Isn't it obvious that allocation of a few KMIDs basically and a few > checks upon them by the responder is a much cheaper mechanism to satisfy > above requirement than brute-force verification of each and every > received option by the receiver? > In summary, your main concern seem to boil down into the scenario where you try to negotiate different MIKEY types (DH, PK, PS) at the same time. The key management negotiation was intended for negotiation of different key management protocols and not negotiation of one and the same protocol. This is a position we still hold. Therefore, we do not see the need for a specific KMID indicating key management protocol's specific offer types. Best, /Mats and MIKEY team _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 12:34:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20652 for ; Wed, 27 Oct 2004 12:34:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMqyK-0001EN-4n for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 12:48:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqhF-0003zV-TR; Wed, 27 Oct 2004 12:30:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMqgR-0003kK-Fs for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 12:30:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20438 for ; Wed, 27 Oct 2004 12:29:55 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMqu5-00018E-KA for mmusic@ietf.org; Wed, 27 Oct 2004 12:44:21 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9RGTJdj015321; Wed, 27 Oct 2004 12:29:19 -0400 (EDT) Message-ID: <417FCCC9.3020509@dynamicsoft.com> Date: Wed, 27 Oct 2004 12:28:57 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng Subject: Re: [MMUSIC] Confusion regarding ICE username fragment References: <758B5A159B385447B4F950DE72D7D7AD714D32@srsdmail01.PVNS.COM> In-Reply-To: <758B5A159B385447B4F950DE72D7D7AD714D32@srsdmail01.PVNS.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit inline. Thomas Zeng wrote: >>If you don't do this, you run into a nasty problem which is >>there is no way to reliably know that your peer has suceeded >>in its connectivity checks. That is needed to allow you to >>turn off the stun server and accept only media packets. This >>also simplified the protocol in several places. > > > I'd like to point out that there are use cases for keeping STUN server > running on the chosen endpoint (i.e., ) even after > connectivity checks have succeeded. > > For RTSP where media packets flow one way from the RTSP server to its > client, it is useful to keep periodic STUN exchanges to keep alive the > NAT bindings. It is known in the real world that cerntain NAT bindings > will be deleted if there is no traffic going a specific direction > (normally from outside in, if I remember correctly). Right. ICE does currently say that this is an application problem, and in this context, it would mean using things like comfort noise of perhaps the rtp no-op format from the client to the RTSP server. Have you considered that? If we want to use STUN for keepalives, the problem you run into is how the client knows whether the stun server is still running or not. If its not, the client shouldnt send the STUn packets; if it is, it can. The -03 draft solves this by using the transmission and receipt of RTP packets onto that address/port as a means for synchronizing this transition. If you leave it flexible as to whether it stays running or not, now you need to signal and syncrhonize on it, adding additional protocol options (a bad thing in general) and complexity. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 13:43:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26277 for ; Wed, 27 Oct 2004 13:43:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMs3V-0002lO-OZ for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 13:57:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrnR-0003Ya-Ey; Wed, 27 Oct 2004 13:41:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMrfk-0000vp-Tx for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 13:33:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25090 for ; Wed, 27 Oct 2004 13:33:17 -0400 (EDT) Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMrta-0002Tm-KY for mmusic@ietf.org; Wed, 27 Oct 2004 13:47:43 -0400 Received: from dynamicsoft.com ([63.113.46.5]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id i9RHWpdj015361; Wed, 27 Oct 2004 13:32:53 -0400 (EDT) Message-ID: <417FDBAD.5070903@dynamicsoft.com> Date: Wed, 27 Oct 2004 13:32:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Awais Ali Subject: Re: [MMUSIC] updated ICE spec References: <417DE7E5.5020401@dynamicsoft.com> <417ED0B4.8050904@i2telecom.com> In-Reply-To: <417ED0B4.8050904@i2telecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: IETF MMUSIC WG X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit inline. Awais Ali wrote: > Jonathan Rosenberg wrote: > >> >> * previously, a client obtained local transport addresses and then >> both used those in its SDP, in addition to deriving perhaps several >> derived transport addresses from it. No longer. No, there is a single >> local transport address for each derived transport address, and that >> local transport address is never advertised in ICE. This turned out to >> be needed to figure out whether the local stun service could be turned >> off when an RTP packet is received. Unfortunately it also required me >> to introduce more terminology to describe. >> > If I understand correctly to fulfill this requirement a device that uses > both TURN and STUN and is starting an RTP/RTCP session will open six > sockets(3 for RTP and 3 for RTCP) and run a STUN server on each of them Yes. > > The advantage of this approach as you mentioned is that the STUN service > can be stopped when an RTP packet is received. Right. Let me explain why you need this. Lets say I have a local socket S1 listening for UDP packets. I use STUN and TURN to derive two additional address/port pairs for that socket. I send them out in an invite. THere is one stun server listening on S1. My peer in the call will perform connectivity checks to *all three* address/port pairs, all three of which will be stun requests against the single server on S1. Now, S1 gets an RTP packet. Presumably, this is because at least one connectivity check has succeeded for the peer. However, it has three connectivity checks to do, all three of which are against the same socket, all three of whicih, if successful, could result in an RTP packet being received on that socket. Unfortunately, I cannot tell from the RTP packet alone *which* of these three checks has succeeded and thus generated an RTP packet. As a result, there is no way for me to know if I may still get valid STUn requests which need to be checked in order for connectivity checks to continue. With TURN, you can sort-of guess by looking at the source address of the packet, and if that is the TURN server, you know that the RTP was sent to the TURN derived address. But, with STUN derived addresses this won't work. By maintaining a single socket, single server, single username, single password, single advertised address model, this problem went away (receipt of an RTP packet on a socket means that connectivity was established to the one transport address advertised for that scoket). It also simplified other parts of the protocol. Now, I well recognize that there is a cost to this in terms of socket resources. I concluded that in practice it didnt look like an issue, but it is something to take note of, and I welcome broader feedback on this point. What will be the downside > of keeping the STUN service running? If you keep it running, you need to specify what happens when these checks fail, specify the periodicity of the checks, worry about congestion control for them. Its interesting to note that these are very much application layer (i.e., rtp and payload format) kinds of issues generally. Furthermore, folks have complained about the difficultty in demuxing RTP/STUN perpetually. With this approach, a socket starts stun only but waits for an RTP packet, and when one arrives, the socket becomes RTP only. There were some on the list who favored this. If you ake it optional about whether it runs or not, you need to solve some negotiation problems as I described in another note. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 15:59:05 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07952 for ; Wed, 27 Oct 2004 15:59:05 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMuAk-0005qb-C8 for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 16:13:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMtrh-0007k4-Fh; Wed, 27 Oct 2004 15:53:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMthu-00044x-2J for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 15:43:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06892 for ; Wed, 27 Oct 2004 15:43:39 -0400 (EDT) Received: from webadmin.keyvoice.com ([12.153.69.6] helo=home.ringle.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMtvm-0005PH-E3 for mmusic@ietf.org; Wed, 27 Oct 2004 15:58:05 -0400 Received: by home.ringle.org (Postfix, from userid 501) id 04F57B7F3D; Wed, 27 Oct 2004 15:42:48 -0400 (EDT) From: Jon Ringle To: mmusic@ietf.org Date: Wed, 27 Oct 2004 15:42:47 -0400 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410271542.47623.ml-mmusic@ringle.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [MMUSIC] ICE Call setup latency X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ml-mmusic@ringle.org List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit The -03 ICE draft in Figure 2, shows the Accept message occuring before the STUN checks are performed. I believe that this is because the STUN checks can't be performed until both the Initiator and Responder have created their connection tables. However the Accept message seems to imply that the user has accepted the call. The media won't flow until the after the connectivity checks has selected a usable transport address. This gives me concern in that normally when a user Accepts a call, the user speaks a greeting (ie. "Hello"). The greeting could be dropped because media from the Responder hasn't begun yet when it is spoken. Might I suggest that the Accept message shown as step (4) be replaced with a Provisional message (which for SIP could map to a 183 Early Media response). The connectivity checks could then be done before the user Accepts the call. Jon _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 18:10:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21023 for ; Wed, 27 Oct 2004 18:10:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwEO-0000ZI-Mu for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 18:25:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvs2-0002qa-2I; Wed, 27 Oct 2004 18:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CM5Xt-0004yb-S0 for mmusic@megatron.ietf.org; Mon, 25 Oct 2004 10:10:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27687 for ; Mon, 25 Oct 2004 10:09:59 -0400 (EDT) Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CM5lL-0007Pr-Oh for mmusic@ietf.org; Mon, 25 Oct 2004 10:23:56 -0400 Received: from eunahT6124 (eunah.etri.re.kr [129.254.112.200]) by pec.etri.re.kr (8.12.10/8.12.10) with SMTP id i9PESslm011209 for ; Mon, 25 Oct 2004 23:28:54 +0900 (KST) Message-ID: <025101c4ba9c$3e4573a0$c870fe81@eunahT6124> From: "Eunsook Kim" To: Date: Mon, 25 Oct 2004 23:09:29 +0900 Organization: etri MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 2.2 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Wed, 27 Oct 2004 18:02:16 -0400 Subject: [MMUSIC] draft-ekim-mmusic-sdp-membership X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eunsook Kim List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1474292973==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 --===============1474292973== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SSBzdWJtaXR0ZWQgYSBkcmFmdCBkZWZpbmVzIGEgc2V0IG9mIFNEUCBhdHRyaWJ1dGVzIA0KZm9y IHNwZWNpZnlpbmcgYW5kIG5lZ290aWF0aW5nIHZlcnkgYmFzaWMgY29uZmVyZW5jZSBtZW1iZXJz aGlwIHBvbGljeS4NClhDT04tV0cgaXMgd29ya2luZyBvbiBhIHNwZWNpZmljIGNvbmZlcmVuY2Ug cG9saWN5LCANCmFuZCB0aG9zZSBpbmZvcm1hdGlvbiBjYW4gYmUgZXhjaGFuZ2VkIGJ5IHRoZSBz cGVjaWZpYyBwcm90b2NvbC4NCkhvd2V2ZXIsIGZvciB1c2VycyB0aG9zZSB3aG8gZG8gbm90IGhh dmUgc3VjaCBwcm90b2NvbCwgYW5kDQpzdGlsbCB3YW50IHRvIHNldCB2ZXJ5IGJhc2ljIHBvbGlj eSBvZiBncm91cCBzZXNzaW9uLA0KdGhlIFNEUCBpbmZvcm1hdGlvbiB3aXRoIG9mZmVyL2Fuc3dl ciBtb2RlbCBjYW4gYmUgdXNlZC4NCg0KVGhlIGRyYWZ0IGNhbiBiZSBmb3VuZCBhdCANCmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWVraW0tbW11c2ljLXNkcC1tZW1i ZXJzaGlwLTAxLnR4dA0KDQpJJ2xsIGFwcHJlY2lhdGUgYW55IGNvbW1lbnRzIGFuZCB0aG91Z2h0 cyBmcm9tIG90aGVyIGZvbGtzLg0KDQpldW5haA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCi0gRXVuc29vayBLaW0gKEV1bmFoKQ0KU2VuaW9yIFJlc2VhcmNoZXIvUGguRA0KRVRSSS8g UHJvdG9jb2wgRW5naW5lZXJpbmcgQ2VudGVyDQpPKTgyLTQyLTg2MC02MTI0LCBNKTgyLTExLTk3 MTEtMTQ2Ng== --===============1474292973== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1474292973==-- From mmusic-bounces@ietf.org Wed Oct 27 18:11:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21170 for ; Wed, 27 Oct 2004 18:11:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwF7-0000aa-8R for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 18:26:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvs2-0002qf-Dz; Wed, 27 Oct 2004 18:02:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMcGR-0000Hm-2B for mmusic@megatron.ietf.org; Tue, 26 Oct 2004 21:06:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17267 for ; Tue, 26 Oct 2004 21:06:09 -0400 (EDT) Received: from [69.55.225.91] (helo=www.implementers.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMcTs-0008Tg-7c for mmusic@ietf.org; Tue, 26 Oct 2004 21:20:24 -0400 Received: by www.implementers.org (Postfix, from userid 1006) id A9FF02FFA292; Tue, 26 Oct 2004 18:05:47 -0700 (PDT) Received: from [10.1.28.2] (localhost [127.0.0.1]) by www.implementers.org (Postfix) with ESMTP id A382D2FFA291; Tue, 26 Oct 2004 18:05:41 -0700 (PDT) Message-ID: <417EF478.70604@petit-huguenin.org> Date: Tue, 26 Oct 2004 18:06:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.3) Gecko/20041008 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [MMUSIC] ICE Issue: mid-session connectivity checks References: <41765E18.1050900@dynamicsoft.com> <200410210915.18122.ml-mmusic@ringle.org> <417D0EEE.2010801@cisco.com> <417DE241.4020603@dynamicsoft.com> In-Reply-To: <417DE241.4020603@dynamicsoft.com> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.implementers.org X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Oct 2004 18:02:16 -0400 Cc: Paul Kyzivat , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Paul, > > I've come around to this line of thinking too, and this is what is > reflected in -03, now available at: > > http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-03.txt > > more inline. > [snip] >> >> For two way RTP based audio media this may, as Jon suggests, only >> require checking that packets are received periodically, and helping >> the other end by always sending packets periodically. For one way or >> idle media this may be a bit more tricky. Sending STUN packets is >> perhaps one answer, but maybe it is ok to send rtp idle packets (did >> those get approved?) if it is agreed they can be sent even on a >> RECVONLY or INACTIVE connection. > > > If you want to monitor quality, I think RTCP does the job. I don't think > you need to send additional packets to generate data to measure. In any > case, determining that there has been a quality failure is definitely > outside the scope of ICE. Using RTCP to monitor the quality of the current best connection is OK, but what about the other routes? The advantage of the connectivity checks with STUN, is that it is possible to use them to measure dynamically the latency/packet lost in the middle of a media session, and so to eventually choose a different route. I understand that this is outside ICE scope, but having this connectivite checks had some interesting usages, and I do not see by what it is replaced. > > In -03, STUN is now only used for the initial checks. mid-call > keepalives are handled at the application layer, and there is text on > doing that for RTP, which talks about this music-on-hold problem. That > is differnt still from detecting failed media to do something about it, > which is not addressed at all, beyond a hook I left. > > The hook that's in there is the treatment of re-invites. If you get one, > and nothing has changed, don't do anything. That is, a re-invite in and > of itself does not trigger you to restart connectivity checks. But, if > the re-invite adds a new candidate address that hasn't been seen before, > connecitivyt checks are sent to it. "never seen before" is determined > based on boht the transport address AND the username fragment. This > means that a client can use a transport address, and then if it thinks > there are problems, start up the stun server again, change the username, > and do a reinvite to trigger a recheck. > > >> > -Jonathan R. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: marc@8x8.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 18:17:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22011 for ; Wed, 27 Oct 2004 18:17:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwKh-0000jk-MU for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 18:32:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMw53-0001B4-EO; Wed, 27 Oct 2004 18:15:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMvz3-00064o-Dd for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 18:09:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20814 for ; Wed, 27 Oct 2004 18:09:30 -0400 (EDT) Received: from [198.66.222.32] (helo=i2telecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMwCz-0000XR-Vd for mmusic@ietf.org; Wed, 27 Oct 2004 18:23:58 -0400 Received: from [127.0.0.1] (adsl-64-171-55-1.dsl.snfc21.pacbell.net [64.171.55.1]) (authenticated bits=0) by i2telecom.com (8.13.1/8.12.11) with ESMTP id i9RM9O2K006938 for ; Wed, 27 Oct 2004 22:09:25 GMT Message-ID: <41801CA5.6060604@i2telecom.com> Date: Wed, 27 Oct 2004 15:09:41 -0700 From: Awais Ali User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] updated ICE spec References: <417DE7E5.5020401@dynamicsoft.com> <417ED0B4.8050904@i2telecom.com> <417FDBAD.5070903@dynamicsoft.com> In-Reply-To: <417FDBAD.5070903@dynamicsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: >> >> The advantage of this approach as you mentioned is that the STUN >> service can be stopped when an RTP packet is received. > > > Right. Let me explain why you need this. > > Lets say I have a local socket S1 listening for UDP packets. I use > STUN and TURN to derive two additional address/port pairs for that > socket. I send them out in an invite. THere is one stun server > listening on S1. My peer in the call will perform connectivity checks > to *all three* address/port pairs, all three of which will be stun > requests against the single server on S1. Now, S1 gets an RTP packet. > Presumably, this is because at least one connectivity check has > succeeded for the peer. However, it has three connectivity checks to > do, all three of which are against the same socket, all three of > whicih, if successful, could result in an RTP packet being received on > that socket. Unfortunately, I cannot tell from the RTP packet alone > *which* of these three checks has succeeded and thus generated an RTP > packet. As a result, there is no way for me to know if I may still get > valid STUn requests which need to be checked in order for connectivity > checks to continue. > Ok I understand that it is not possible to determine from the RTP packet which connection was used. Why can we not use the Giveup timer to determine when the client has stopped its connectivity checks?. If a maximum Giveup-time is specified, a peer can stop its STUN server, Giveup-time after receiving the first RTP packet. Ali _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 20:09:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00011 for ; Wed, 27 Oct 2004 20:09:56 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMy5W-0002yO-W1 for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 20:24:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxr0-0003dv-5f; Wed, 27 Oct 2004 20:09:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMxn5-0003AE-Pl for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 20:05:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29845 for ; Wed, 27 Oct 2004 20:05:18 -0400 (EDT) Received: from [198.66.222.32] (helo=i2telecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMy12-0002uZ-RG for mmusic@ietf.org; Wed, 27 Oct 2004 20:19:46 -0400 Received: from [127.0.0.1] (adsl-64-171-55-1.dsl.snfc21.pacbell.net [64.171.55.1]) (authenticated bits=0) by i2telecom.com (8.13.1/8.12.11) with ESMTP id i9S05FAO049449 for ; Thu, 28 Oct 2004 00:05:17 GMT Message-ID: <418037CD.6060900@i2telecom.com> Date: Wed, 27 Oct 2004 17:05:33 -0700 From: Awais Ali User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Clarification about ICE Management of Resources X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit I would like to verify if my understanding of the Management of Resources section in the ICE draft is correct. Let us assume device A and device B want to establish an RTP/RTCP session. A and B have 3 addresses each, as follows: AL: local address of A AS: Stun derived address for A AT: Turn derived address for A BL: local address of B BS: Stun derived address for B BT: Turn derived address for B After A completes its connectivity checks, A's connection table for RTP will look like this 1. AS BS ... ... ... 0.2 GOOD 2. AS BT ... ... ... 0.1 GOOD 3. AS BL ... ... ... 0.4 BAD 4. AT BS ... ... ... 0.2 GOOD 5. AT BT ... ... ... 0.1 GOOD 6. AT BL ... ... ... 0.4 BAD 7. AL BS ... ... ... 0.2 GOOD 8. AL BT ... ... ... 0.1 GOOD 9. AL BL ... ... ... 0.4 BAD Lets say A selects Line 7 to send RTP packets, then A will keep the other five connections open by sending keep-alive packets on them. Similarly there will be 5 RTCP channels. So in total A has to keep-alive 10 connections. B will also have a simillar connnection table. If B also selects the BL AS line for sending Media packets, then in the above exampe, we will have the situation where A is sending from a different port than it is receiving on. In this case then A must send keep alive packets from AS to keep the NAT binding open, even if it decides not to keep the other connections as backup. Thanks Ali _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Oct 27 21:48:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07459 for ; Wed, 27 Oct 2004 21:48:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMzdP-0004ht-5h for mmusic-web-archive@ietf.org; Wed, 27 Oct 2004 22:03:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMzOB-000180-UI; Wed, 27 Oct 2004 21:47:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMzNy-00012I-4i for mmusic@megatron.ietf.org; Wed, 27 Oct 2004 21:47:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07412 for ; Wed, 27 Oct 2004 21:47:28 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMzbw-0004gR-Dv for mmusic@ietf.org; Wed, 27 Oct 2004 22:01:57 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 27 Oct 2004 18:35:24 -0700 X-BrightmailFiltered: true Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9S1Z89b025622; Wed, 27 Oct 2004 18:35:08 -0700 (PDT) Received: from DWINGW2K4 (sjc-vpn2-434.cisco.com [10.21.113.178]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id SAA07213; Wed, 27 Oct 2004 18:35:08 -0700 (PDT) From: "Dan Wing" To: "Marc Petit-Huguenin" , "Jonathan Rosenberg" Subject: RE: [MMUSIC] ICE Issue: mid-session connectivity checks Date: Wed, 27 Oct 2004 18:35:07 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <417EF478.70604@petit-huguenin.org> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Paul Kyzivat , mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit > Using RTCP to monitor the quality of the current best connection is > OK, but what about the other routes? The advantage of the > connectivity checks with STUN, is that it is possible to use them to > measure dynamically the latency/packet lost in the middle of a media > session, and so to eventually choose a different route. I understand > that this is outside ICE scope, but having this connectivite checks > had some interesting usages, and I do not see by what it is replaced. An endpoint is still free to probe other paths if it wants to do so. Changing the path during an active call results in out-of-order packet delivery, the possibility of lost packets, and a high likelyhood that the delay of the new path will be different than the delay of the old path. In may situations, these changes cause an adverse effect on realtime, interactive media (audio or video). As networks are designed to reduce these very same adverse effects, it's not desirable for a NAT optimization technique to continually probe and potentially switch media paths during an active media session. -d _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Oct 28 13:59:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03300 for ; Thu, 28 Oct 2004 13:59:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEmj-000065-Jw for mmusic-web-archive@ietf.org; Thu, 28 Oct 2004 14:14:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCks-0003Nr-Qk; Thu, 28 Oct 2004 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBmB-0005rJ-5b; Thu, 28 Oct 2004 11:01:19 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21483; Thu, 28 Oct 2004 11:01:18 -0400 (EDT) Message-Id: <200410281501.LAA21483@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:01:18 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-03.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --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 : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Multimedia Session Establishment Protocols Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-03.txt Pages : 45 Date : 2004-10-27 This document describes a methodology for Network Address Translator (NAT) traversal for multimedia session signaling protocols, such as the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN) and Traversal Using Relay NAT (TURN). ICE makes use of STUN in peer-to-peer cooperative fashion, allowing participants to discover, create and verify mutual connectivity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-ice-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-ice-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110122.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 28 14:02:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03661 for ; Thu, 28 Oct 2004 14:02:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEpj-0000ED-1x for mmusic-web-archive@ietf.org; Thu, 28 Oct 2004 14:17:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCl3-0003e5-T2; Thu, 28 Oct 2004 12:04:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBmV-00060s-MJ; Thu, 28 Oct 2004 11:01:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21545; Thu, 28 Oct 2004 11:01:38 -0400 (EDT) Message-Id: <200410281501.LAA21545@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:01:38 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --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-08.txt Pages : 176 Date : 2004-10-27 This memorandum is a revision of RFC 2326, which is currently a Proposed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable 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 protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110128.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 28 14:05:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04514 for ; Thu, 28 Oct 2004 14:05:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEsx-0000Vz-PB for mmusic-web-archive@ietf.org; Thu, 28 Oct 2004 14:20:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNClC-0003rc-W3; Thu, 28 Oct 2004 12:04:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBmr-0006Em-A2; Thu, 28 Oct 2004 11:02:01 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21619; Thu, 28 Oct 2004 11:02:00 -0400 (EDT) Message-Id: <200410281502.LAA21619@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:02:00 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-21.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : M. Handley, et al. Filename : draft-ietf-mmusic-sdp-new-21.txt Pages : 46 Date : 2004-10-27 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-21.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-new-21.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-21.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: <2004-10-28110133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-21.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-21.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110133.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Thu Oct 28 14:08:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05193 for ; Thu, 28 Oct 2004 14:08:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNEvE-0000kG-R5 for mmusic-web-archive@ietf.org; Thu, 28 Oct 2004 14:22:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNClO-00046a-21; Thu, 28 Oct 2004 12:04:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBnT-0006VS-Uq; Thu, 28 Oct 2004 11:02:40 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21758; Thu, 28 Oct 2004 11:02:39 -0400 (EDT) Message-Id: <200410281502.LAA21758@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 11:02:38 -0400 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-anat-02.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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 : The Alternative Network Address Types Semantics (ANAT) for theSession Description Protocol (SDP) Grouping Framework Author(s) : G. Camarillo, J. Rosenberg Filename : draft-ietf-mmusic-anat-02.txt Pages : 8 Date : 2004-10-27 This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework. The ANAT semantics allow offering alternative types of network addresses to establish a particular media stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-anat-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-anat-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-mmusic-anat-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: <2004-10-28110139.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-anat-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-anat-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110139.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --NextPart-- From mmusic-bounces@ietf.org Sat Oct 30 06:00:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12388 for ; Sat, 30 Oct 2004 06:00:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNqGn-0007Cd-Q5 for mmusic-web-archive@ietf.org; Sat, 30 Oct 2004 06:15:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNpmF-00076j-KW; Sat, 30 Oct 2004 05:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNphH-0003xF-FL for mmusic@megatron.ietf.org; Sat, 30 Oct 2004 05:38:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11214 for ; Sat, 30 Oct 2004 05:38:52 -0400 (EDT) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNpvj-0006rE-DA for mmusic@ietf.org; Sat, 30 Oct 2004 05:53:52 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61559 helo=[192.168.0.5]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CNpgj-0002jp-QI for mmusic@ietf.org; Sat, 30 Oct 2004 10:38:22 +0100 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200410281502.LAA21619@ietf.org> References: <200410281502.LAA21619@ietf.org> Content-Type: multipart/mixed; boundary=Apple-Mail-4-562813650 Message-Id: <6DEBAFC3-2A57-11D9-8597-000A957FC5F2@csperkins.org> From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-21.txt Date: Sat, 30 Oct 2004 10:38:17 +0100 To: IETF MMUSIC Working Group X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8df1ceff7d5e1ba4a25ab9834397277b X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff --Apple-Mail-4-562813650 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 28 Oct 2004, at 16:02, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Multiparty Multimedia Session Control > Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : M. Handley, et al. > Filename : draft-ietf-mmusic-sdp-new-21.txt > Pages : 46 > Date : 2004-10-27 > > This memo defines the Session Description Protocol (SDP). SDP is > intended for describing multimedia sessions for the purposes of > session announcement, session invitation, and other forms of > multimedia session initiation. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-21.txt Changes in this version are: - In section 4.1, clarify that the transport port for unicast IP sessions is the remote transport port. - In section 5.1, clarify that the media description is optional. - In section 5.7, clarify that "this memo only defines IP4 and IP6", rather than "currently only IP4 and IP6 are defined". - In section 5.7, note that TTL scoping is NOT RECOMMENDED for multicast, and one should use admin-scoped addresses instead. - Rename section 6 from "Suggested Attributes" to "SDP Attributes" - In section 5.8, clarify that the bandwidth is in kilobits per second unless otherwise specified in the definition of a new modifier. - In section 5.9, clarify that the end time SHOULD be specified unless a session is unbounded. - In section 5.12, remove example of SIP-over-TLS, since that's not an end to end connection. - In section 5.13, remove example of use of attributes. - In section 5.14, clarify behaviour when two RTP sessions share the same transport address. - Section 5.14 was missing a reference to the "application" top-level MIME type for the "udp" proto. - In section 6, generalise "a=orient" slightly. Remove references to the "wb" application, which is of historical interest only. - In section 6, specify that "a=maxptime" is an integer multiple of the frame size for frame based codecs - In section 7, reference SIP and offer/answer security considerations. - In section 7, note that firewall holes should only be opened when the user can be appropriately authenticated and is authorized to do so. - In ABNF: a comment suggested that UDP ports should either be 0 or in the range 1024-65535. This conflicts with existing usage (e.g. port 9 is used by comedia) and wasn't mandated by the text. Remove the comment, to allow any UDP port to be used. - In ABNF: allow DNS names for multicast groups - In ABNF: a comment in the definition of "sess-version" noted that 0 indicates a new session. This conflicted with section 5.2, which said that an NTP-format timestamp SHOULD be used. Accordingly, the comment has been removed. - In ABNF: allow 127.0.0.1 as a valid IPv4 address Colin --Apple-Mail-4-562813650 Content-Type: text/plain; x-unix-mode=0660; name="20-21.diff.txt" Content-Disposition: attachment; filename=20-21.diff.txt Content-Transfer-Encoding: 7bit Index: sdp.xml =================================================================== RCS file: /Users/csp/CVS/sdp/sdp.xml,v retrieving revision 1.37 retrieving revision 1.66 diff -u -r1.37 -r1.66 --- sdp.xml 2004/09/19 09:02:11 1.37 +++ sdp.xml 2004/10/25 12:36:10 1.66 @@ -6,7 +6,7 @@ + docName="draft-ietf-mmusic-sdp-new-21.txt"> SDP: Session Description Protocol @@ -48,7 +48,7 @@ csp@csperkins.org - + This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of @@ -228,7 +228,7 @@ For unicast IP sessions, the following are conveyed: The remote address for media - The transport port for media + The remote transport port for media The semantics of this address and port depend on the media and @@ -351,7 +351,7 @@ Session description v= (protocol version) - o= (owner/creator and session identifier). + o= (owner/creator and session identifier) s= (session name) i=* (session information) u=* (URI of description) @@ -370,7 +370,7 @@ t= (time the session is active) r=* (zero or more repeat times) - Media description + Media description, if present m= (media name and transport address) i=* (media title) c=* (connection information - optional if included at @@ -415,9 +415,8 @@ t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 - m=video 51372 RTP/AVP 31 - m=application 32416 udp wb - a=orient:portrait + m=video 51372 RTP/AVP 99 + a=rtpmap:99 h263-1998/90000 Text fields such as the session name and information are octet @@ -525,7 +524,7 @@ The "i=" field provides textual information about the session. - There may be at most one session-level "i=" field per session + There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is @@ -554,7 +553,7 @@ A URI is a Universal Resource Identifier as used by WWW clients , . The URI should be a pointer to additional information about the - conference. This field is OPTIONAL, but if it is present it MUST + session. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description. @@ -640,7 +639,7 @@ The second sub-field ("<addrtype>") is the address type. This allows SDP to be used for sessions that are not IP based. - Currently only IP4 and IP6 are defined, but other values MAY be + This memo only defines IP4 and IP6, but other values MAY be registered in the future (see Section 8). The third sub-field ("<connection-address>") is the connection @@ -660,12 +659,14 @@ description that is communicated by a multicast announcement, though this is not prohibited. - Conferences using an IPv4 multicast connection address MUST + Sessions using an IPv4 multicast connection address MUST also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this conference will be sent. TTL values MUST be in the range - 0-255. + 0-255. While the TTL MUST be specified, its use to scope + multicast traffic is deprecated; applications SHOULD use + an adminstratively scoped address instead. The TTL for the session is appended to the address using a slash @@ -768,7 +769,8 @@ If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=CT:..." line SHOULD be supplied for the session giving the proposed upper limit - to the bandwidth used. The primary purpose of this is to give an + to the bandwidth used (the "conference total" bandwidth). The + primary purpose of this is to give an approximate idea as to whether two or more sessions can co-exist simultaneously. When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to @@ -804,9 +806,10 @@ given, they are recommended to be short. - The <bandwidth> is in kilobits per second by default. - Modifiers MAY specify that alternative units are to be used (the - modifiers defined in this memo use the default units). + The <bandwidth> is interpreted as kilobits per second by default. + The definition of a new <bwtype> modifier MAY specify that the + bandwidth is to be interpreted in some alternative unit (the "CT" + and "AS" modifiers defined in this memo use the default units).
@@ -850,7 +853,7 @@ sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time or the session start time, whichever is the later. If - behaviour other than this is required, an end-time should be given + behaviour other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end. @@ -1039,7 +1042,7 @@ The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message - or a TLS protected HTTP or SIP session. It is important to ensure + or a TLS-protected HTTP session. It is important to ensure that the secure channel is with the party that is authorized to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or @@ -1066,8 +1069,7 @@ stream. 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. + to individual media. Attribute fields may be of two forms: @@ -1096,7 +1098,7 @@ values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be - charset-dependent, in which case it's value should be interpreted + charset-dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646. Attributes MUST be registered with IANA (see Section 8). If an @@ -1178,6 +1180,36 @@ would imply that address 224.2.1.1 is used with ports 49170 and 49171, and address 224.2.1.2 is used with ports 49172 and 49173. + The combination of ports specified in "m=" lines and IP addresses + specified in "c=" lines MUST comply with the following rules for + RTP-based media streams (other protocols SHOULD define similar + rules): + + + If two media sessions have the same transport address (i.e. + identical IP address and port numbers), the associated + payload types (e.g. given in the "a=rtpmap:" attribute) + MUST NOT be in conflict, i.e. the same payload type MUST + NOT be mapped to different media types. + + If two media sessions have the same transport address, they + MUST use compatible media (e.g. both audio or both video). + + If two media sessions have the same transport address, they + SHOULD operate under the same RTP profile. The sessions MAY + use two different RTP profiles only if those profiles are + specifically designed to be compatible. + + If two media sessions have the same RTP transport address, + they MUST also use the same RTCP address and vice versa. + + + Two media sessions with the same transport address indicate + alternatives for the same media stream, i.e. all profiles, + media types, and payload types provided in any of the "m=" + lines are valid. + + is the transport protocol. The meaning of the transport protocol is dependent on the address type field in the relevant "c=" field. Thus a "c=" field of IP4 indicates that @@ -1201,7 +1233,7 @@ the media format is that the same standard media formats may be carried over different transport protocols even when the network protocol is the same - a historical example is vat PCM audio and - RTP PCM audio. In addition, relays and monitoring tools that are + RTP PCM audio, another might be TCP/RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. is a media format description. The fourth @@ -1222,9 +1254,9 @@ If the <proto> sub-field is "udp" the <fmt> sub-fields MUST reference a media type describing the format under the - "audio", "text" and "video" top-level MIME types. The media - type registration SHOULD define the packetization format for - use with UDP transport. + "audio", "video", "text" and "application" top-level MIME types. + The media type registration SHOULD define the packetization + format for use with UDP transport. For media using other transport protocols, the <fmt> field is protocol specific. Rules for interpretation of the <fmt> @@ -1235,7 +1267,7 @@
-
+
The following attributes are defined. Since application writers may add new attributes as they are required, this list @@ -1283,15 +1315,14 @@ The maximum amount of media which can be encapsulated in each packet, expressed as time in milliseconds. The time SHALL be calculated as the sum of the time the media present in the - packet represents. The time SHOULD be a multiple of the frame - size. This attribute is probably only meaningful for audio - data, but may be used with other media types if it makes - sense. It is a media attribute, and is not dependent on - charset. Note that this attribute was introduced after RFC - 2327, and non updated implementations will ignore this - attribute. + packet represents. For frame based codecs, the time SHOULD + be an integer multiple of the frame size. This attribute is + probably only meaningful for audio data, but may be used with + other media types if it makes sense. It is a media attribute, + and is not dependent on charset. Note that this attribute was + introduced after RFC 2327, and non updated implementations will + ignore this attribute. - a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>] @@ -1382,10 +1413,10 @@ This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic - source. In such a case, two media descriptions may be use, + source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session or media attribute, but would normally only be used as a media - attribute, and is not dependent on charset. Note that sendonly + attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g. RTCP) SHOULD still be received and processed as normal. @@ -1398,13 +1429,13 @@ still send RTCP, even if started inactive. It can be either a session or media attribute, and is not dependent on charset. - a=orient:<whiteboard orientation> + a=orient:<orientation> - Normally this is only used in a whiteboard media specification. - It specifies the orientation of a the whiteboard on the screen. - It is a media attribute. Permitted values are "portrait", - "landscape" and "seascape" (upside down landscape). It is not - dependent on charset. + Normally this is only used for a whiteboard or presentation + tool. It specifies the orientation of a the workspace on + the screen. It is a media attribute. Permitted values are + "portrait", "landscape" and "seascape" (upside down landscape). + It is not dependent on charset. a=type:<conference type> @@ -1546,6 +1577,11 @@
+ SDP is frequently used with the Session Initiation + Protocol using the offer/answer model + to agree parameters for unicast sessions. When used in this manner, the + security considerations of those protocols apply. + SDP is a session description format that describes multimedia sessions. A session description SHOULD NOT be trusted unless it has been obtained by an authenticated transport protocol from a trusted @@ -1592,14 +1628,12 @@ Session descriptions may be parsed at intermediate systems such as firewalls for the purposes of opening a hole in the firewall to allow - the participation in multimedia sessions. It is considered - inappropriate for a firewall to open such holes for unicast data - streams unless the session description comes in a request from inside - the firewall. For multicast sessions, it is likely that local - administrators will apply their own policies, but the exclusive use - of "local" or "site-local" administrative scope within the firewall - and the refusal of the firewall to open a hole for such scopes will - provide separation of global multicast sessions from local ones. + participation in multimedia sessions. This SHOULD NOT be done unless + the SDP is conveyed in a manner that allows proper authentication and + authorization checks to ensure that firewall holes are only opened in + accordance with applicable security policy. SDP by itself does not + include sufficient information to enable these checks: they depend on + the encapsulating protocol (e.g. SIP or RTSP). Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used @@ -1969,7 +2003,6 @@ ;should be unique for this username/host sess-version = 1*DIGIT - ;0 is a new session nettype = token ;typically "IN" @@ -2055,15 +2088,12 @@ ;typically "RTP/AVP" or "udp" port = 1*DIGIT - ;should be either "0" or in the range "1024" - ;to "65535" inclusive for UDP based media - ;(a value of "0" is used to signal special - ;conditions in some uses of SDP) ; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr - multicast-address = IP4-multicast / IP6-multicast / extn-addr + multicast-address = IP4-multicast / IP6-multicast / FQDN + / extn-addr IP4-multicast = m1 3( "." decimal-uchar ) "/" ttl [ "/" integer ] @@ -2080,12 +2110,12 @@ FQDN = 4*(alpha-numeric / "-" / ".") ; fully qualified domain name as specified - ; in RFC1035 + ; in RFC1035 (and updates) - IP4-address = b1 3("." decimal-uchar) / "0.0.0.0" + IP4-address = b1 3("." decimal-uchar) b1 = decimal-uchar - ; less than "224"; not "0" or "127" + ; less than "224" ; The following is from RFC2373 Appendix B. It is a direct copy. IP6-address = hexpart [ ":" IP4-address ] --Apple-Mail-4-562813650 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --Apple-Mail-4-562813650-- From mmusic-bounces@ietf.org Sun Oct 31 21:11:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24742 for ; Sun, 31 Oct 2004 21:11:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CORtq-0002Cf-SN for mmusic-web-archive@ietf.org; Sun, 31 Oct 2004 21:26:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CORdo-0000db-7d; Sun, 31 Oct 2004 21:09:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CORcr-0000X9-Ip for mmusic@megatron.ietf.org; Sun, 31 Oct 2004 21:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24374 for ; Sun, 31 Oct 2004 21:08:51 -0500 (EST) Received: from mx-s1.dreamwiz.com ([211.39.128.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CORre-00029X-UN for mmusic@ietf.org; Sun, 31 Oct 2004 21:24:11 -0500 X-DreamWiz-SpamCenter: C=0, M=1, R=1, BR=0, BRS=0, BRT=0, SPAM=0, FL=0, VC=PASS(2004-11-01) X-DreamWiz-Peer-IP: [10.0.0.30] Received: from mail10.dreamwiz.com (mail10.dreamwiz.com [10.0.0.30]) by mx-s1.dreamwiz.com (8.13.1/8.13.1) with ESMTP id iA128jLQ001238 for ; Mon, 1 Nov 2004 11:08:46 +0900 (KST) Received: from [127.0.0.1] (localhost.dreamwiz.com [127.0.0.1]) by mail10.dreamwiz.com (8.13.1/8.13.1) with ESMTP id iA128jVs006270 for ; Mon, 1 Nov 2004 11:08:45 +0900 (KST) Received: from [129.254.112.200] by mail10.dreamwiz.com with HTTP; Mon, 1 Nov 2004 11:08:45 +0900 (KST) Date: Mon, 1 Nov 2004 11:08:45 +0900 (KST) From: =?EUC-KR?B?sejAurz3?= To: mmusic@ietf.org Message-ID: <20041101020845.0000186C02AD02E7@mail10.dreamwiz.com> X-Priority: 3 X-Originating-IP: [129.254.112.200] X-Originating-Email: eunah714@dreamwiz.com X-Mailer: DreamWiz Web-Mailer V4.01P03 MIME-Version: 1.0 X-Spam-Score: 2.2 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [MMUSIC] draft-ekim-mmusic-sdp-membership X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1652652401==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 2.5 (++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 --===============1652652401== Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY="0-1804289383-1099274925=:6252" --0-1804289383-1099274925=:6252 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII I submitted a draft defines a set of SDP attributes for specifying and negotiating very basic conference membership policy. XCON-WG is working on a specific conference policy, and those information can be exchanged by the specific protocol. However, for users those who do not have such protocol, and still want to set very basic policy of group session, the SDP information with offer/answer model can be used. The draft can be found at http://www.ietf.org/internet-drafts/draft-ekim-mmusic-sdp-membership-01.txt I'll appreciate any comments and thoughts from other folks. eunah ------------------------------------------------- Your Life on the Net DreamWiz Free Mail @ http://www.dreamwiz.com/ --0-1804289383-1099274925=:6252 Content-Type: TEXT/HTML; CHARSET=EUC-KR X-MIME-Autoconverted: from 8bit to quoted-printable by mx-s1.dreamwiz.com id iA128jLQ001238 Content-Transfer-Encoding: quoted-printable
I submitted a draft defines a set of SDP attributes=20
for specifying and negotiating very basic conference membership polic= y.
XCON-WG is working on a specific conference policy,=20
and those information can be exchanged by the specific protocol.
However, for users those who do not have such protocol, and
still want to set very basic policy of group session,
the SDP information with offer/answer model can be used.

The draft can be found at=20
http://www.ietf.org/internet-drafts/draft-ekim-mmusic-sdp-membership-= 01.txt

I'll appreciate any comments and thoughts from other folks.

eunah






=BB=FD=C8=B0=C0=CE=C5=CD=B3=DD =B5=E5=B8=B2=C0=A7=C1=EE h= ttp://www.dreamwiz.com/

= [=B9=AB=C7=D1=B8=DE=C0=CF] 228M=B5=B5 =BA=CE=C1= =B7=C7=CF=B8=E9 =B9=AB=C7=D1=C0=B8=B7=CE =BD=F5=B4=CF=B4=D9. &nb= sp; [=B5=F0=BD=BA=C5=A9] 128M =B0=F8=C2=A5 = =B5=F0=BD=BA=C5=A9 =B0=A1=C1=F6=B7=AF =B0=A1=C0=DA! =20 --0-1804289383-1099274925=:6252-- --===============1652652401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic --===============1652652401==--