From mailman-bounces@ietf.org Mon Nov 1 08:53: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 IAA03387 for ; Mon, 1 Nov 2004 08:53:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COcs6-0007bC-QO for mmusic-web-archive@ietf.org; Mon, 01 Nov 2004 09:09:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZj3-0008P5-6M for mmusic-web-archive@ietf.org; Mon, 01 Nov 2004 05:47:49 -0500 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: Mon, 01 Nov 2004 05:18:48 -0500 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 Mon Nov 1 16:54: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 QAA08745 for ; Mon, 1 Nov 2004 16:54:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COkMp-0005AE-Ni for mmusic-web-archive@ietf.org; Mon, 01 Nov 2004 17:09:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COjdJ-00089B-1Y; Mon, 01 Nov 2004 16:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COixZ-0002CB-QJ for mmusic@megatron.ietf.org; Mon, 01 Nov 2004 15:39:26 -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 PAA28435 for ; Mon, 1 Nov 2004 15:39:22 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COjCX-0002HP-82 for mmusic@ietf.org; Mon, 01 Nov 2004 15:54:54 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 01 Nov 2004 12:41:30 -0800 X-BrightmailFiltered: true Received: from [192.168.1.101] (sjc-vpn1-252.cisco.com [10.21.96.252]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iA1KcmJZ000942; Mon, 1 Nov 2004 12:38:49 -0800 (PST) Message-ID: <41869ED7.9090007@cisco.com> Date: Mon, 01 Nov 2004 15:38:47 -0500 From: Flemming Andreasen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joerg Ott Subject: Re: [MMUSIC] MMUSIC at 61st IETF References: <4173D91D.4050204@tzi.uni-bremen.de> In-Reply-To: <4173D91D.4050204@tzi.uni-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Flemming Andreasen , Mark Baugher , Dan Wing , Dave Oran , Colin Perkins , 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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Hi Joerg and Colin We have updates to the following two drafts, which we presented in Seoul: 1. Security preconditions (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-securityprecondition-02.txt) 2. Connectivity preconditions (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-connectivityprecondition-01.txt) I'm not aware of any open technical issues with either draft, but can present them both again if you like. Also, I'd appreciate your thoughts on what the next steps for each of these drafts should be. Thanks -- Flemming Joerg Ott wrote: > 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 2 10:35: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 KAA01828 for ; Tue, 2 Nov 2004 10:35:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0w8-0004Up-GB for mmusic-web-archive@ietf.org; Tue, 02 Nov 2004 10:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0QO-0007Aq-2f; Tue, 02 Nov 2004 10:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0Fn-0008Gq-7u for mmusic@megatron.ietf.org; Tue, 02 Nov 2004 10:07:23 -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 KAA27644 for ; Tue, 2 Nov 2004 10:07:21 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0Uu-0003hR-Nz for mmusic@ietf.org; Tue, 02 Nov 2004 10:23:01 -0500 Received: from alor.dcs.gla.ac.uk ([130.209.247.84]:55300) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CP0FG-0000Vj-Nz; Tue, 02 Nov 2004 15:06:50 +0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Colin Perkins Date: Tue, 2 Nov 2004 15:06:44 +0000 To: IETF MMUSIC Working Group X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Joerg Ott Subject: [MMUSIC] Draft agenda for Washington DC 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: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit A draft agenda is attached. Comments, corrections and additions to the chairs please. Colin ======================================================================== === Multiparty Multimedia Session Control (MMUSIC) Working Group CHAIRS: Joerg Ott Colin Perkins Monday, 8th November 2004 at 09:00-11:30 ======================================== Introduction and Status Update (Chairs) 10 Remote Camera Control -> AVT draft-ietf-mmusic-anat-02.txt draft-ietf-mmusic-offer-answer-examples-05.txt draft-ietf-mmusic-rfc2326bis-08.txt draft-ietf-mmusic-rtsp-announce-00.txt draft-ietf-mmusic-sdp-comedia-09.txt draft-ietf-mmusic-comedia-tls-02.txt draft-wing-mmusic-symmetric-rtprtcp-01.txt draft-ekim-mmusic-sdp-membership-01.txt Application Sharing (Schulzrinne) 10 draft-schulzrinne-mmusic-sharing-00.txt Interactive Connectivity Establishment (ICE) (Rosenberg) 30 draft-ietf-mmusic-ice-03.txt Internet Media Guides (Nomura) 20 draft-nomura-mmusic-img-notify-00.txt draft-walsh-mmusic-img-envelope-01.txt SDP (Perkins) 10 draft-ietf-mmusic-sdp-new-21.txt SDP Extension for Media Loopback (Hedayat) 10 draft-hedayat-media-loopback-01.txt SDP Format for Binary Floor Control Protocol (BFCP) (Camarillo) 10 draft-camarillo-mmusic-sdp-bfcp-00.txt SDP Label Attribute (Camarillo) 5 draft-ietf-mmusic-sdp-media-label-00.txt SDP Connection-Establishment Precondition (Camarillo) 5 draft-ietf-mmusic-connection-precon-00.txt SDP Security Precondition (Andreasen) 5 draft-andreasen-mmusic-securityprecondition-02.txt SDP Connectivity Precondition (Andreasen) 5 draft-andreasen-mmusic-connectivityprecondition-01.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 04:32: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 EAA14991 for ; Wed, 3 Nov 2004 04:32:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPHkx-00077g-KO for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 04:48:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPHI2-0002f1-Si; Wed, 03 Nov 2004 04:18:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPH8W-00070s-8x for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 04:09:00 -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 EAA13283 for ; Wed, 3 Nov 2004 04:08:58 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPHNo-0006c1-1Z for mmusic@ietf.org; Wed, 03 Nov 2004 04:24:48 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iA398wfO009141 for ; Wed, 3 Nov 2004 10:08:58 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iA398wma001253 for ; Wed, 3 Nov 2004 10:08:58 +0100 Resent-Message-Id: <200411030908.iA398wma001253@mail1.siemens.de> Message-Id: <200411030908.iA398wma001253@mail1.siemens.de> Resent-from: "Steffen Fries" Resent-to: mmusic@ietf.org Resent-date: Wed, 03 Nov 2004 10:08:53 +0100 X-cs: R From: Steffen Fries X-RS-ID: X-RS-Flags: 0,0,1,1,0,0,0 X-RS-Sigset: -1 To: mats.naslund@ericsson.com MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8BIT Date: Wed, 03 Nov 2004 09:49:20 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8BIT Cc: mmusic-request@ietf.org 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 Reply-To: steffen.fries@siemens.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: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 8BIT Hi, I was just reading over the discussion regarding the bidding down attacks with respect to draft-ietf-mmusic-kmgmt-ext-11.txt and the DHHMAC draft (extension to MIKEY). I understand the argumentation that just checking the the SDP part may not help. I have a scenario in mind which I don't see covered by the current discussion: Let's assume somebody includes two MIKEY offers in an INVITE, one for PW based encryption and one for public key encryption. The SDP payload for this would look like a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. were the first line is bound to the password based encryption method and the second to the public key encryption method. Now, the protocol list, which goes to MIKEY to be protected would be "mikey;mikey". Assuming that an attacker may have gotten my password (the assumption is not a weak MIKEY method), he might be interested in replacing the second line by the first line. The integrity protection of "mikey;mikey" is still vaild, but the responder doesn't really have a choice since both offers are equeal. I'm not sure if this example is somewhat constructed, but I think the responder wouldn't even notice that a MITM changed the offer (unless protected by other means like TLS or S/MIME). Taking the approach from Martin would at least enable the receiver that something changed, even if he may not be able to process the other MIKEY method. How does the current draft deal with such a situation? Regards Steffen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 06:19: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 GAA24594 for ; Wed, 3 Nov 2004 06:19:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJQW-00018n-LP for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 06:35:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPItg-0002Tt-7X; Wed, 03 Nov 2004 06:01:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPIAY-0002R6-GT for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 05:15:11 -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 FAA18085 for ; Wed, 3 Nov 2004 05:15:08 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPIPp-00088J-I7 for mmusic@ietf.org; Wed, 03 Nov 2004 05:30:59 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iA3AF3P6029314; Wed, 3 Nov 2004 11:15:03 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iA3AF3ma010228; Wed, 3 Nov 2004 11:15:03 +0100 From: "Steffen Fries" Organization: Siemens AG To: "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Wed, 03 Nov 2004 11:14:58 +0100 MIME-Version: 1.0 Message-ID: <4188BDB2.13898.297354F7@localhost> Priority: normal In-reply-to: <4188A9EE.7050202@ericsson.com> References: <4188A99E.7582.2924E8DF@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-description: Mail message body X-Spam-Score: 0.9 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: mmusic@ietf.org 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 Reply-To: steffen.fries@siemens.com List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1999522463==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f --===============1999522463== Content-type: text/html; charset=US-ASCII Content-description: Mail message body Content-Transfer-Encoding: 7BIT
Hi Mats,

i put my comments also inline:


> Hi Steffen,
>
> Thanks for the additional comments. Our reply is inline.
>
> Steffen Fries wrote:
>
> > Hi,
> >
> > I was just reading over the discussion regarding the bidding
> > down attacks with respect to draft-ietf-mmusic-kmgmt-ext-11.txt and
> > the DHHMAC draft (extension to MIKEY).
> >
> > I understand the argumentation that just checking the the SDP
> > part may not help. I have a scenario in mind which I don't see
> > covered by the current discussion:
> > Let's assume somebody includes two MIKEY offers in an INVITE,
> > one for PW based encryption and one for public key encryption.
> > The SDP payload for this would look like
> >
> >    a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..
> >    a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD..
> >
> > were the first line is bound to the password based encryption
> > method and the second to the public key encryption method. Now, the
> > protocol list, which goes to MIKEY to be protected would be
> > "mikey;mikey".
> >
> > Assuming that an attacker may have gotten my password (the
> > assumption is not a weak MIKEY method), he might be interested
> > in replacing the second line by the first line. The integrity
> > protection of "mikey;mikey" is still vaild, but the responder
> > doesn't really have a choice since both offers are equeal. I'm
> > not sure if this example is somewhat constructed, but I think
>
> Well, let's make another construction. Suppose we do introduce
> Martin's suggestion and that all else is as you assume above.
>
> The initiator sends something like
>
>      a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..
>      a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD..

I actually thought here on something like
     a=key-mgmt:mikeyPW dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..
     a=key-mgmt:mikeyPS uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD..
which would enable an easier processing as Matin suggested.

> where the both lines use the protocol list "mikeyPK; mikeyPW".
> Since the attacker knows the password, he could just as easily
> delete the first offer altogether and fake the (single) offer
>
>      a=key-mgmt:mikey <something>
>
> which is a mikeyPW offer using the protocol list "mikeyPW"
> (Guess this is equivalent to your attack but with a different
> "flavor"). This would also be a bidding down attack, but
> the extended list format does not help against this.
Agreed

> In fact, if the Initiator is not even on line, the fact
> that the attacker knows the password enables him to generate
> arbitrary (single) mikeyPW offers at any time, regardless
> of the format of the protocol list.
>
>
> > the responder wouldn't even notice that a MITM changed the offer
> > (unless protected by other means like TLS or S/MIME). Taking the
>
> Same in our example.
>
> > approach from Martin would at least enable the receiver that
> > something changed, even if he may not be able
> > to process the other MIKEY method.
>
> Our view is that to demonstrate the need for the extended identifiers
> you need to make the assumption of an existing serious security hole
> (a VERY weak MIKEY version, the knowledge of a key/password, etc). But
> in that case there are much worse things to worry about than the
> bidding-down issue. And, even *with* the extended identifiers the
> bidding down problem remains in that case as we hope we showed above.
Okay, I got your point. Just for my curiosity, with this argument, what is the point to protect the KMGT IDs by the key management protocol at all? If some property like the password is known, a MITM may replace the complete key management offer with something else (like in your example). If a weak protocol is used than you have the chance that the attacker is not able to break it in the normal call setup time. Is that the goal?


regards
      Steffen
>
> We thus do not believe the "real" security issue is solved
> by the extension of the protocol IDs. Why would an attacker wait
> to see "real" offers flying by and then change them, when he
> can attack himself at any time?
>
> >
> > How does the current draft deal with such a situation?
> >
> > Regards
> >         Steffen
> >
>
> It is not addressed specifically.
>
> Regardless of the above, we again emphasize that the negotiation
> mechanism of key management protocols is intended for different
> protocols, not negotiating different types of the same protocol.
>
> Best,
>
> /Mats and MIKEY team
>
>
>

--===============1999522463== 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 --===============1999522463==-- From mmusic-bounces@ietf.org Wed Nov 3 07:31: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 HAA02183 for ; Wed, 3 Nov 2004 07:31:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKYC-00030E-1p for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 07:47:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKA2-0006MU-4d; Wed, 03 Nov 2004 07:22:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPK0z-0005Ai-A9 for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 07:13:25 -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 HAA00156 for ; Wed, 3 Nov 2004 07:13:21 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKGI-0002ag-4L for mmusic@ietf.org; Wed, 03 Nov 2004 07:29:14 -0500 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 iA3CDMfM000171 for ; Wed, 3 Nov 2004 13:13:22 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 13:13:22 +0100 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 WB1ZWV9D; Wed, 3 Nov 2004 13:13:21 +0100 Message-ID: <4188CB61.6050706@ericsson.com> Date: Wed, 03 Nov 2004 13:13:21 +0100 X-Sybari-Trust: 44a1ba99 8cefd49f 6486bc69 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: steffen.fries@siemens.com References: <4188BDB2.13898.297354F7@localhost> In-Reply-To: <4188BDB2.13898.297354F7@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 12:13:22.0019 (UTC) FILETIME=[83028330:01C4C19E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org 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: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Hi again Steffen, Steffen Fries wrote: > Hi Mats, > > i put my comments also inline: > > >> Hi Steffen, >> >> Thanks for the additional comments. Our reply is inline. >> >> Steffen Fries wrote: >> >> > Hi, >> > >> > I was just reading over the discussion regarding the bidding >> > down attacks with respect to draft-ietf-mmusic-kmgmt-ext-11.txt and >> > the DHHMAC draft (extension to MIKEY). >> > >> > I understand the argumentation that just checking the the SDP >> > part may not help. I have a scenario in mind which I don't see >> > covered by the current discussion: >> > Let's assume somebody includes two MIKEY offers in an INVITE, >> > one for PW based encryption and one for public key encryption. >> > The SDP payload for this would look like >> > >> > a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. >> > a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. >> > >> > were the first line is bound to the password based encryption >> > method and the second to the public key encryption method. Now, the >> > protocol list, which goes to MIKEY to be protected would be >> > "mikey;mikey". >> > >> > Assuming that an attacker may have gotten my password (the >> > assumption is not a weak MIKEY method), he might be interested >> > in replacing the second line by the first line. The integrity >> > protection of "mikey;mikey" is still vaild, but the responder >> > doesn't really have a choice since both offers are equeal. I'm >> > not sure if this example is somewhat constructed, but I think >> >> Well, let's make another construction. Suppose we do introduce >> Martin's suggestion and that all else is as you assume above. >> >> The initiator sends something like >> >> a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. >> a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. > > I actually thought here on something like > a=key-mgmt:mikeyPW dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. > a=key-mgmt:mikeyPS uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. > which would enable an easier processing as Matin suggested. Oh, sure, this was a typo by me. Nevertheless the issues remain as we seem to agree (and just "seeing" mikeyX at this point doesn't mean you can trust it until after the line has been parsed and authenticated.) > >> where the both lines use the protocol list "mikeyPK; mikeyPW". >> Since the attacker knows the password, he could just as easily >> delete the first offer altogether and fake the (single) offer >> >> a=key-mgmt:mikey >> >> which is a mikeyPW offer using the protocol list "mikeyPW" >> (Guess this is equivalent to your attack but with a different >> "flavor"). This would also be a bidding down attack, but >> the extended list format does not help against this. > Agreed > >> In fact, if the Initiator is not even on line, the fact >> that the attacker knows the password enables him to generate >> arbitrary (single) mikeyPW offers at any time, regardless >> of the format of the protocol list. >> >> >> > the responder wouldn't even notice that a MITM changed the offer >> > (unless protected by other means like TLS or S/MIME). Taking the >> >> Same in our example. >> >> > approach from Martin would at least enable the receiver that >> > something changed, even if he may not be able >> > to process the other MIKEY method. >> >> Our view is that to demonstrate the need for the extended identifiers >> you need to make the assumption of an existing serious security hole >> (a VERY weak MIKEY version, the knowledge of a key/password, etc). But >> in that case there are much worse things to worry about than the >> bidding-down issue. And, even *with* the extended identifiers the >> bidding down problem remains in that case as we hope we showed above. > Okay, I got your point. Just for my curiosity, with this argument, what > is the point to protect the KMGT IDs by the key management protocol at > all? If some property like the password is known, a MITM may replace the > complete key management offer with something else (like in your > example). If a weak protocol is used than you have the chance that the > attacker is not able to break it in the normal call setup time. Is that > the goal? The inclusion of the (authenticated) protocol list is mainly to protect against somebody *deleting* an entire a-line which (had it been received) would have been the Responder's preferred choice. For example, say I offer you one a-line based on MIKEY and one based on ProtocolZ (maybe because I have your public key, but I am not sure which protocol support). Now suppose the MITM just deletes the MIKEY line but lets ProtocolZ pass. Assuming you support ProtcolZ, you will probably accept that, but you might actually have preferred MIKEY (for security or other reasons). The protocol list gives a way for you to check that *something* was lost along the way. Similarly, if I offer you three MIKEY options (though we do not see that as realistic) the Responder can detect if one or two were deleted by an attacker. He cannot detect *what* the other offers were, but he does detect the attack. Hope this clarifies the rationale. /Mats and MIKEY team _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 07:48:27 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 HAA03777 for ; Wed, 3 Nov 2004 07:48:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKoE-0003cG-Gm for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 08:04:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKTy-0002Il-Rw; Wed, 03 Nov 2004 07:43:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKPS-0001Bt-5M for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 07:38:42 -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 HAA02735 for ; Wed, 3 Nov 2004 07:38:40 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKek-0003Bf-PT for mmusic@ietf.org; Wed, 03 Nov 2004 07:54:32 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id iA3CcPfO028221; Wed, 3 Nov 2004 13:38:25 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iA3CcPma026194; Wed, 3 Nov 2004 13:38:25 +0100 From: "Steffen Fries" Organization: Siemens AG To: "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Wed, 03 Nov 2004 13:38:20 +0100 MIME-Version: 1.0 Message-ID: <4188DF4C.9575.29F696F4@localhost> Priority: normal In-reply-to: <4188CB61.6050706@ericsson.com> References: <4188BDB2.13898.297354F7@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7BIT Cc: mmusic@ietf.org 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 Reply-To: steffen.fries@siemens.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: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7BIT Hi Mats, I've a question to your last point: > Similarly, if I offer you three MIKEY options (though we do not see > that as realistic) the Responder can detect if one or two were deleted > by an attacker. He cannot detect *what* the other offers were, but he > does detect the attack. Given the example we used before: a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. were the first line is bound to the password based encryption method and the second to the public key encryption method. Now, the protocol list, which goes to MIKEY to be protected would be "mikey;mikey". By replacing line 2 with line 1 you force the receipient to go with MIKEY PW, even he would have preferred MIKEY PK. And the integrity check here should be fine. Is it worth to mention this attack somewere in the security considerations? Regards Steffen ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 10:27:22 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 KAA19190 for ; Wed, 3 Nov 2004 10:27:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPNI3-0007kn-Nm for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 10:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMsi-0006bb-MT; Wed, 03 Nov 2004 10:17:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMkh-0003nj-P4 for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 10:08:47 -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 KAA16676 for ; Wed, 3 Nov 2004 10:08:45 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPN01-0007G6-LO for mmusic@ietf.org; Wed, 03 Nov 2004 10:24:39 -0500 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 iA3F8jfM015126 for ; Wed, 3 Nov 2004 16:08:45 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Nov 2004 16:08:45 +0100 Received: from ericsson.com (research-64de67.ki.sw.ericsson.se [147.214.118.190]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VJSNT2NQ; Wed, 3 Nov 2004 16:08:44 +0100 Message-ID: <4188F47C.9040203@ericsson.com> Date: Wed, 03 Nov 2004 16:08:44 +0100 X-Sybari-Trust: e41fcbc7 bfd556f1 57bc3e07 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: steffen.fries@siemens.com References: <4188DF4C.9575.29F696F4@localhost> In-Reply-To: <4188DF4C.9575.29F696F4@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Nov 2004 15:08:45.0117 (UTC) FILETIME=[0343D6D0:01C4C1B7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Ciao Steffen, Steffen Fries wrote: > Hi Mats, > > I've a question to your last point: > > > Similarly, if I offer you three MIKEY options (though we do not see > > that as realistic) the Responder can detect if one or two were deleted > > by an attacker. He cannot detect *what* the other offers were, but he > > does detect the attack. > > Given the example we used before: > > a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/.. > a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD.. > > were the first line is bound to the password based encryption > method and the second to the public key encryption method. Now, > the protocol list, which goes to MIKEY to be protected would be > "mikey;mikey". By replacing line 2 with line 1 you force the > receipient to go with MIKEY PW, even he would have preferred > MIKEY PK. And the integrity check here should be fine. Yes, this is possible if you (still contrary to intent) negotiate within the same protocol. The duplication is still in principle detectable though (by pure semantics), since it makes no sense to offer *exactly* the same twice. In fact, even technically, how could the Responder choose between two apparently identical offers without parsing them? According to MIKEY RFC, any MIKEY message that has come in and been authenticated should be in the replay cache. Thus, a compliant MIKEY implementation should in fact automatically catch the second line as a replay. > > Is it worth to mention this attack somewere in the security > considerations? Not sure, but with reference to this (long) discussion leading (in our opinion) to the conclusion that not even misuse of the functionality has any real security implication, we believe that perhaps it is the intended use of multi-offer that should be elaborated? Best, /Mats and MIKEY team _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 11:39:34 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 LAA24734 for ; Wed, 3 Nov 2004 11:39:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPOPw-0000rS-Hf for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 11:55:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNyf-0003vq-K0; Wed, 03 Nov 2004 11:27:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNuH-000338-5R for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 11:22:45 -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 LAA23426 for ; Wed, 3 Nov 2004 11:22:43 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPO9d-0000Wj-18 for mmusic@ietf.org; Wed, 03 Nov 2004 11:38:37 -0500 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iA3GMcBO023861; Wed, 3 Nov 2004 17:22:38 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id iA3GMbma014207; Wed, 3 Nov 2004 17:22:37 +0100 From: "Steffen Fries" Organization: Siemens AG To: "=?ISO-8859-1?Q?Mats_N=E4slund?=" Date: Wed, 03 Nov 2004 17:22:31 +0100 MIME-Version: 1.0 Message-ID: <418913D7.10505.2AC3D756@localhost> Priority: normal In-reply-to: <4188F47C.9040203@ericsson.com> References: <4188DF4C.9575.29F696F4@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7BIT Cc: mmusic@ietf.org 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 Reply-To: steffen.fries@siemens.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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT Hi Mats, > > Yes, this is possible if you (still contrary to intent) negotiate > within the same protocol. The duplication is still in principle > detectable though (by pure semantics), since it makes no sense to > offer *exactly* the same twice. correct, it makes not sense, it was just a constructed scenario > > In fact, even technically, how could the Responder choose between two > apparently identical offers without parsing them? According to MIKEY > RFC, any MIKEY message that has come in and been authenticated should > be in the replay cache. Thus, a compliant MIKEY implementation should > in fact automatically catch the second line as a replay. good point, I did not think on the replay cache as both offers are transmitted in the same message. But that would be detected. > > > > > Is it worth to mention this attack somewere in the security > > considerations? > > Not sure, but with reference to this (long) discussion leading > (in our opinion) to the conclusion that not even misuse of the > functionality has any real security implication, we believe that > perhaps it is the intended use of multi-offer that should be > elaborated? yes, I think it would be worth to provide more infos here. Maybe once in a while people having the same thoughts I had, then it is good to reflect the result of the discussion within the draft. Regards Steffen--------------------------------------------------- -------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 3 19:16: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 TAA05856 for ; Wed, 3 Nov 2004 19:16:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPVXy-0003Zu-35 for mmusic-web-archive@ietf.org; Wed, 03 Nov 2004 19:32:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPV4Y-0003XC-FX; Wed, 03 Nov 2004 19:01:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPV32-00035v-2I for mmusic@megatron.ietf.org; Wed, 03 Nov 2004 19:00:16 -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 TAA05054 for ; Wed, 3 Nov 2004 19:00:12 -0500 (EST) Received: from flawless.real.com ([207.188.23.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPVIR-0003Hv-EL for mmusic@ietf.org; Wed, 03 Nov 2004 19:16:11 -0500 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; Wed, 03 Nov 2004 15:59:38 -0800 Message-Id: <6.1.2.0.2.20041103154225.0895d128@mailone.real.com> X-Sender: rmathew@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 03 Nov 2004 16:01:46 -0800 To: Magnus Westerlund From: Rishi Mathew Subject: Re: [MMUSIC] Transport Header Stipulation In-Reply-To: <4174D936.2080109@ericsson.com> References: <6.1.2.0.2.20041012111619.0847a220@mailone.real.com> <4174D936.2080109@ericsson.com> 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: dbb8771284c7a36189745aa720dc20ab 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: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Magnus, Sorry for the late response... Comments inline.. At 01:07 AM 10/19/2004, Magnus Westerlund wrote: >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 Ok.. >>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? The current wording as I understand it, precludes efficient negotiation of transport. For example, let's say that RDT is preferred, but RTP is acceptable. This would be expressed by the requestor as: Transport: x-real-rdt/udp;client_port=6970;mode=play,RTP/AVP/UDP;client_port=6970;mode=play In the (intended) RFC 2326 world, a server that doesn't understand RDT would return: Transport: RTP/AVP/UDP;client_port=6970;server_port=17738 However, in the current specification, this would result in another round trip, as the SETUP would fail and would need to be reissued. Worse, in many current RFC 2326 implementations, the connection would be torn down. Dont you think it is worth REQUIRING new server implementations to ignore a particular transport and go on to the next one if there is something they cannot understand and parse? Thanks, Rishi. >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 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 Thu Nov 4 02:41: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 CAA22634 for ; Thu, 4 Nov 2004 02:41:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPcUo-0004Qd-28 for mmusic-web-archive@ietf.org; Thu, 04 Nov 2004 02:57:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPcDx-0001qe-7V; Thu, 04 Nov 2004 02:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPc65-0000VL-C5 for mmusic@megatron.ietf.org; Thu, 04 Nov 2004 02:31: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 CAA21807 for ; Thu, 4 Nov 2004 02:31:52 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPcLY-0004D4-Qo for mmusic@ietf.org; Thu, 04 Nov 2004 02:47:53 -0500 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 iA47VoP6006723; Thu, 4 Nov 2004 08:31:50 +0100 Received: from mchn070c (mhpaba5c.mchp.siemens.de [139.23.204.46]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA47VoBO001075; Thu, 4 Nov 2004 08:31:50 +0100 From: "Steffen Fries" Organization: Siemens AG To: "=?ISO-8859-1?Q?Mats_N=E4slund?=" , elisabetta.carrara@ericsson.com Date: Thu, 04 Nov 2004 08:31:41 +0100 MIME-Version: 1.0 Message-ID: <4189E8ED.17354.2E043472@localhost> Priority: normal In-reply-to: <41891E83.6060809@ericsson.com> References: <418913D7.10505.2AC3D756@localhost> X-mailer: Pegasus Mail for Windows (4.21c) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: Quoted-printable Cc: mmusic@ietf.org 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 Reply-To: steffen.fries@siemens.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: Quoted-printable Hi Mats, yes, I will talk with Elisabetta in Washington. Anyway, I think we cleared the points mostly and I think whats left is only the reflection of the result in the draft in a way that everybody understands it. Regards Steffen Date sent: Wed, 03 Nov 2004 19:08:03 +0100 From: Mats N=E4slund To: steffen.fries@siemens.com, "Elisabetta Carrara (KI/EAB)" Subject: Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA consid= erations section > > Hi again Steffen, > > I saw no reason to go "public" with this: > > Steffen Fries wrote: > > > yes, I think it would be worth to provide more infos here. Maybe > > once in a while people having the same thoughts I had, then it is > > good to reflect the result of the discussion within the draft. > > It was very good that you (and Martin) brought this up. One would > indeed wish that this whole email exchange could be included in the > RFC so as to settle it once and for all and so that future worries of > this sort could avoided. However, that would make a rather long RFC so > if we do anything about it, it needs to be rather compact text. > > As I understood, you and Elisabetta would probably meet in Washington, > where it may be more efficient with a f2f discussion. > > Thanks, > > /Mats > ----------------------------------------------------------- Steffen Fries, Siemens AG, CT IC 3 Otto-Hahn-Ring 6, D-81730 Munich, Germany Phone: (+49) 89 / 636-53403, Fax : (+49) 89 / 636-48000 Email: Steffen.Fries@siemens.com ----------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Nov 4 18:04:43 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 SAA19737 for ; Thu, 4 Nov 2004 18:04:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPquT-0002A1-TK for mmusic-web-archive@ietf.org; Thu, 04 Nov 2004 18:20:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqZs-00032E-32; Thu, 04 Nov 2004 17:59:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPqRw-0000vq-G4 for mmusic@megatron.ietf.org; Thu, 04 Nov 2004 17:51:24 -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 RAA18171 for ; Thu, 4 Nov 2004 17:51:22 -0500 (EST) Received: from webadmin.keyvoice.com ([12.153.69.6] helo=home.ringle.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPqhY-0001oY-Ip for mmusic@ietf.org; Thu, 04 Nov 2004 18:07:32 -0500 Received: by home.ringle.org (Postfix, from userid 501) id 7451BB7F5B; Thu, 4 Nov 2004 17:48:10 -0500 (EST) From: Jon Ringle To: mmusic@ietf.org, Jonathan Rosenberg Subject: Re: [MMUSIC] ICE Call setup latency Date: Thu, 4 Nov 2004 17:48:10 -0500 User-Agent: KMail/1.5 References: <200410271542.47623.ml-mmusic@ringle.org> In-Reply-To: <200410271542.47623.ml-mmusic@ringle.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411041748.10087.ml-mmusic@ringle.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Ping... On Wednesday 27 October 2004 03:42 pm, Jon Ringle wrote: > 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Nov 5 05:10: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 FAA24723 for ; Fri, 5 Nov 2004 05:10:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ1IT-0006vJ-6H for mmusic-web-archive@ietf.org; Fri, 05 Nov 2004 05:26:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Ss-00061M-3o; Fri, 05 Nov 2004 04:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0Re-0005fC-G5 for mmusic@megatron.ietf.org; Fri, 05 Nov 2004 04:31:46 -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 EAA19889 for ; Fri, 5 Nov 2004 04:31:38 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0hF-0005t9-Us for mmusic@ietf.org; Fri, 05 Nov 2004 04:47:54 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59V7jj022950 for ; Fri, 5 Nov 2004 10:31:07 +0100 Message-Id: <200411050931.iA59V7jj022950@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:31:04 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGiulxH7YXyWrSbSwAYLAXoYaog== X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [MMUSIC] WiMAX Summit: Call for proposals 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="===============1459755427==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --===============1459755427== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0106_01C4C322.8DE0C980" This is a multi-part message in MIME format. ------=_NextPart_000_0106_01C4C322.8DE0C980 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 second edition of the WiMAX Summit, next April 5-8 2005, by distinguished experts and key players in the field. The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_0106_01C4C322.8DE0C980 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 second = edition of the WiMAX Summit, next April 5-8 2005, by distinguished = experts and key players in the field.

 

The call for proposal dead line has been = extended to November 30.

 

Details at:

http://www.upperside.fr/wimax05/wimax2005intro.htm

 

------=_NextPart_000_0106_01C4C322.8DE0C980-- --===============1459755427== 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 --===============1459755427==-- From mmusic-bounces@ietf.org Fri Nov 5 09:21:11 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 JAA15350 for ; Fri, 5 Nov 2004 09:21:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ5DU-0004Bi-1B for mmusic-web-archive@ietf.org; Fri, 05 Nov 2004 09:37:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ4tS-0005Qm-Qg; Fri, 05 Nov 2004 09:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ4lC-0004UC-6y for mmusic@megatron.ietf.org; Fri, 05 Nov 2004 09:08:14 -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 JAA14592 for ; Fri, 5 Nov 2004 09:08:12 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ50k-0003wZ-OQ for mmusic@ietf.org; Fri, 05 Nov 2004 09:24:30 -0500 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 iA5E80vD003431 for ; Fri, 5 Nov 2004 15:08:00 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 Nov 2004 15:07:59 +0100 Received: from [147.214.97.153] (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFZHFT4A; Fri, 5 Nov 2004 15:07:58 +0100 Message-ID: <418B7CBF.2020708@ericsson.com> Date: Fri, 05 Nov 2004 14:14:39 +0100 X-Sybari-Trust: 41b5271e ad48f3dd edabb938 00000179 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.20041103154225.0895d128@mailone.real.com> In-Reply-To: <6.1.2.0.2.20041103154225.0895d128@mailone.real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2004 14:07:59.0321 (UTC) FILETIME=[DB070490:01C4C340] 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 Rishi, Yes, you are right the mechanism to negotiate the transport protocol is needed. See below proposal. Rishi Mathew wrote: > > The current wording as I understand it, precludes efficient negotiation of > transport. For example, let's say that RDT is preferred, but RTP is > acceptable. This would be expressed by the requestor as: > > Transport: > x-real-rdt/udp;client_port=6970;mode=play,RTP/AVP/UDP;client_port=6970;mode=play > > > In the (intended) RFC 2326 world, a server that doesn't understand RDT > would return: > Transport: RTP/AVP/UDP;client_port=6970;server_port=17738 > > However, in the current specification, this would result in another round > trip, as the SETUP would fail and would need to > be reissued. Worse, in many current RFC 2326 implementations, the > connection would be torn down. > > Dont you think it is worth REQUIRING new server implementations to ignore a > particular transport and go on to the next one if there is something they > cannot understand and parse? > Already today there is a sentence in the transport header section: Unknown transport parameters SHALL be ignored. I would propose that one clarifies that this also applies to complete transport specification, and especially the transport protocol identifier. Thus one can include a list of potentially understood transport specifications. However it still leaves the problem of how one indicates that a parameter within a specific transport spec must be understood. Maybe one should create a new transport parameter that takes parameter names that are mandatory for this specification to be understood. That way, one can for each transport protocol define the parameters that must be understood. If some special case requires extension parameters, or normally optional parameters to be understood, then one includes the parameter names in the mandatory parameter. Example: Transport: RTP/AVP;multicast;mode="PLAY", RTP/AVP;unicast;spec_par="xyz";client_port=3456-3457;mode="PLAY";mand="spec_par" Further suggestions or 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 Fri Nov 5 16:09:10 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 QAA18050 for ; Fri, 5 Nov 2004 16:09:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBKZ-0004Mz-RZ for mmusic-web-archive@ietf.org; Fri, 05 Nov 2004 16:09:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBH3-0002GO-4O; Fri, 05 Nov 2004 16:05:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQBEF-00005g-7d for mmusic@megatron.ietf.org; Fri, 05 Nov 2004 16:02:39 -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 QAA17116 for ; Fri, 5 Nov 2004 16:02:37 -0500 (EST) Received: from scarface.real.com ([207.188.7.230]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBU2-00048p-W9 for mmusic@ietf.org; Fri, 05 Nov 2004 16:18:59 -0500 Received: from d845pebt2_xp.real.com ([::ffff:172.22.143.254]) (AUTH: LOGIN rmathew, SSL: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Fri, 05 Nov 2004 13:01:44 -0800 Message-Id: <6.1.2.0.2.20041105125151.08b14550@mailone.real.com> X-Sender: rmathew@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 05 Nov 2004 13:04:12 -0800 To: Magnus Westerlund From: Rishi Mathew Subject: Re: [MMUSIC] Transport Header Stipulation In-Reply-To: <418B7CBF.2020708@ericsson.com> References: <6.1.2.0.2.20041103154225.0895d128@mailone.real.com> <418B7CBF.2020708@ericsson.com> 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: 37af5f8fbf6f013c5b771388e24b09e7 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: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Magnus, Comments inline... At 05:14 AM 11/5/2004, Magnus Westerlund wrote: >Hi Rishi, > >Yes, you are right the mechanism to negotiate the transport protocol is >needed. See below proposal. > >Rishi Mathew wrote: >>The current wording as I understand it, precludes efficient negotiation of >>transport. For example, let's say that RDT is preferred, but RTP is >>acceptable. This would be expressed by the requestor as: >>Transport: >>x-real-rdt/udp;client_port=6970;mode=play,RTP/AVP/UDP;client_port=6970;mode=play >> >>In the (intended) RFC 2326 world, a server that doesn't understand RDT >>would return: >>Transport: RTP/AVP/UDP;client_port=6970;server_port=17738 >>However, in the current specification, this would result in another round >>trip, as the SETUP would fail and would need to >>be reissued. Worse, in many current RFC 2326 implementations, the >>connection would be torn down. >>Dont you think it is worth REQUIRING new server implementations to ignore a >>particular transport and go on to the next one if there is something they >>cannot understand and parse? > >Already today there is a sentence in the transport header section: > > Unknown transport parameters SHALL be ignored. > >I would propose that one clarifies that this also applies to complete >transport specification, and especially the transport protocol >identifier. Thus one can include a list of potentially understood >transport specifications. > >However it still leaves the problem of how one indicates that a >parameter within a specific transport spec must be understood. Maybe one >should create a new transport parameter that takes parameter names that >are mandatory for this specification to be understood. That way, one >can for each transport protocol define the parameters that must be >understood. If some special case requires extension parameters, or >normally optional parameters to be understood, then one includes the >parameter names in the mandatory parameter. > >Example: > >Transport: RTP/AVP;multicast;mode="PLAY", >RTP/AVP;unicast;spec_par="xyz";client_port=3456-3457;mode="PLAY";mand="spec_par" This looks right... but does it mean that if there is a "MUST understand" parameter in a transport that I want to ignore, I have to send back an error? For example, Transport: x-real-rdt/udp;client_port=6970;mode=play;spec_par="xyz";mand="spec_par",RTP/AVP/UDP;client_port=6970;mode=play Lets assume a server does not understand RDT. Preferably, it should just ignore everything until the next "transport" and start from there. But, since there is a mandatory parameter in a transport that it does not understand, will it be forced to return an error? >Further suggestions or comments? I would also suggest that we modify the BNF to reflect the fact that the "profile" makes sense with RTP and not necessarily with other proprietary transport protocols. Current syntax: 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 We could modify the BNF so that everything remains the same for RTP, but for other transport protocols, we could make the "profile" optional. Proposed: transport-id = [ rtp-trans | other-trans ] ; no LWS is allowed inside transport-id rtp-trans = "RTP" "/" profile ["/" lower-transport] ; no LWS is allowed inside transport-id profile = "AVP" / token lower-transport = "TCP" / "UDP" / token other-trans = token [ "/" token ]* Cheers, Rishi. >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 > > > 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 Sun Nov 7 13:03:15 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 NAA08970 for ; Sun, 7 Nov 2004 13:03:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQrOA-0008M8-Tt for mmusic-web-archive@ietf.org; Sun, 07 Nov 2004 13:03:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrIe-0005Je-2K; Sun, 07 Nov 2004 12:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrH8-00056C-12 for mmusic@megatron.ietf.org; Sun, 07 Nov 2004 12:56:26 -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 MAA08619 for ; Sun, 7 Nov 2004 12:56:22 -0500 (EST) 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 1CQrHV-0008EZ-C0 for mmusic@ietf.org; Sun, 07 Nov 2004 12:56:49 -0500 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 iA7HtktL018308; Sun, 7 Nov 2004 18:56:11 +0100 (MET) Message-ID: <418E61A9.1040607@tzi.uni-bremen.de> Date: Sun, 07 Nov 2004 18:55:53 +0100 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, Colin Perkins 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: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Slides for tomorrow 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 Folks, please send a copy of your presentation slides for the Monday MMUSIC session to Colin and myself by 8:00am EST tomorrow so that we can do all the presentations from a single laptop. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 8 05:12: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 FAA17018 for ; Mon, 8 Nov 2004 05:12:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR6Vo-00047P-RI for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 05:12:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR6Ra-0006BB-Sp; Mon, 08 Nov 2004 05:08:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR6BR-00042J-Aw for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 04:51:33 -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 EAA15547 for ; Mon, 8 Nov 2004 04:51:31 -0500 (EST) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CR6Bx-0003i3-3f for mmusic@ietf.org; Mon, 08 Nov 2004 04:52:05 -0500 Received: (qmail 7004 invoked for bounce); 8 Nov 2004 09:51:35 -0000 Received: from unknown (HELO ?130.79.90.163?) (hoerdt@unknown) by unknown with RC4-MD5 encrypted SMTP; 8 Nov 2004 09:51:35 -0000 Message-ID: <418F40C7.7000800@clarinet.u-strasbg.fr> Date: Mon, 08 Nov 2004 10:47:51 +0100 From: Hoerdt Mickael User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 X-Accept-Language: en MIME-Version: 1.0 To: David Meyer References: <20041104154408.GA15370@1-4-5.net> In-Reply-To: <20041104154408.GA15370@1-4-5.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA15547 Cc: mmusic@ietf.org, csp@csperkins.org, mboned@lists.uoregon.edu Subject: [MMUSIC] Re: mboned: updated MBONED agenda 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: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: quoted-printable Hello, I am happy to see that multi-source SSM session layering is still a=20 potential working topic at the IETF. I continued my work, but mainly on the implementation (the API changed)=20 and finally named the very simple protocol that I presented here more =20 than one year ago : Source Specific Multicast Source Discovery Protocol=20 (SSMSDP). It still uses a shared SSM tree to signal new channels=20 presents in the session. Source announcements toward the root of the tree can use TCP or UDP (see=20 the API doc), but are not MSDP formated as in Rami lethonen work. Well known applications (vic/rat/beacon) has been launched without=20 recompilation over SSM with a tool called "ssmsdpifier", it simply trap=20 MROUTING setsockopt with ssmsdp calls. On a 10Mb/s with a single linux=20 PC with 64Mb of ram and 350Mhz the implementation is able to sustain about 1500=20 actives sources signaling on the same process (with an announcement period of 5 sec) Documentation, implementation, Faqs, Status are all there : http://clarinet.u-strasbg.fr/~hoerdt/libssmsdp/ Cheers, Hoerdt Micka=EBl David Meyer a =E9crit : >MBONE Deployment WG (mboned) > >MONDAY, November 8, 2004 (1530-1730) >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >CHAIR: David Meyer > >AGENDA > > o Administriva > > - Mailing list: majordomo@lists.uoregon.edu > subscribe mboned > > - Scribe? > > - Blue Sheets > > o Agenda Bashing 2 minute= s > Meyer =20 > > > o Review and status of work items =20 > > Active Drafts > ------------- > draft-ietf-mboned-ssm232-08.txt 1 minut= e > Shepherd, et al > RFC Ed Queue (BCP) > draft-ietf-mboned-embeddedrp-06.txt 1 minut= e > Savola/Haberman > RFC Ed Queue (PS) > draft-ietf-mboned-mroutesec-04.txt 3 minut= es > Savola et al (Point Raised - writeup needed) > draft-ietf-mboned-msdp-deploy-06.txt 1 minut= e > McBride, et al > RFC Ed Queue (BCP) > draft-ietf-mboned-rfc3171bis-02.txt 2 minut= es > Albanna, et al > (Revised ID Needed) > draft-ietf-mboned-ipv6-multicast-issues-01.txt 5 minut= es > Savola > draft-ietf-mboned-msdp-mib-00.txt 5 minut= es > Fenner/Thaler > draft-ietf-mboned-auto-multicast-03.txt 10 minut= es > Thaler, et al > draft-ietf-mboned-ipv4-uni-based-mcast-02.txt 5 minut= es > Thaler > > Potental WG Drafts > ------------------ > - Overview of the Internet Multicast Addressing Architecture 10 minut= es > draft-savola-mboned-addrarch-00.txt > Savola > > - Dynamic Multi-Source Discovery for SSM using MSDP 10 minut= es > draft-lehtonen-mboned-multissm-01.txt > Lehtonen > > - Accouting Issues In Well Managed IP Multicasting Services 10 minut= es > draft-hayashi-maccnt-01.txt > Hayashi > > o IMDOC=20 > > - MP-LSPs (Requirements/overview of current status) =20 > Introduction 2 minut= es > Meyer > A Chair's view on what MPLS is doing 5 minut= es > Swallow > Summary of Requirements 5 minut= es > Yasukawa Seisho > Proposed Solutions 5 minut= es > Papadimitriou > Discussion 13 minut= es > All > > - p2mp ping and traceroute 10 minut= es > draft-yasukawa-mpls-p2mp-lsp-ping-00.txt > Farrel, et. al. > =20 > - On-link IGMP/MLD/PIM threats and problems 10 minutes > Savola > > >_______________________________________________________________ >user interface: http://darkwing.uoregon.edu/~llynch/mboned.html >web archive: http://darkwing.uoregon.edu/~llynch/mboned/ > =20 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 8 06:57:28 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 GAA25347 for ; Mon, 8 Nov 2004 06:57:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR89t-0006Cu-3S for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 06:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR84u-0003m3-7L; Mon, 08 Nov 2004 06:52:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR7zG-0003Nw-LW for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 06:47:07 -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 GAA24369 for ; Mon, 8 Nov 2004 06:47:03 -0500 (EST) Received: from s-utl01-dcpop.stsn.com ([63.240.218.73]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CR7zn-0005z3-QM for mmusic@ietf.org; Mon, 08 Nov 2004 06:47:40 -0500 Received: from dcpop.smtp.stsn.com ([127.0.0.1]) by s-utl01-dcpop.stsn.com (SAVSMTP 3.1.0.29) with SMTP id M2004110806470431181 for ; Mon, 08 Nov 2004 06:47:04 -0500 Received: from [10.67.87.102] ([10.67.87.102]) by dcpop.smtp.stsn.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Nov 2004 06:47:04 -0500 Message-ID: <418F5CB5.4030409@cisco.com> Date: Mon, 08 Nov 2004 06:47:01 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Awais Ali Subject: Re: [MMUSIC] Clarification about ICE Management of Resources References: <418037CD.6060900@i2telecom.com> In-Reply-To: <418037CD.6060900@i2telecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2004 11:47:04.0582 (UTC) FILETIME=[AAD97A60:01C4C588] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit inline. Awais Ali wrote: > 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 > Right so far. > 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. No. In the current draft, it would only keep alive the one its using, since keepalives are done at the application layer and therefore imply usage of the address. > Similarly there will be 5 RTCP channels. So in total A has to keep-alive > 10 connections. No, just two (RTP and RTCP). > > 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. Hmm, in -03, yes it would appear that this would happen. 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. This is an excellent point, thank you for pointing it out. It is a definite problem in the specification, since right now those keepalives are not happening. What needs to happen is that you end up with a symmetric relationship, where both sides send to, and receive from, the same address. As such, you need to add an algorithm to the spec to select the source address in a much more deterministic way. I'd suggest that the following algorithm works: A client MUST send from the transport address on which it most recently received an RTP packet. If there is no such address (as no RTP packets are being received yet), it SHOULD send from the transport address of highest local priority on which a STUN connectivity check has been received. If there is no such address (as no connectivity checks have been received yet), it SHOULD send from the local transport address of highest priority. The first sentence of this paragraph achieves the desired effect - it will force media to be sent from the same port on which it is being received. The remaining sentences help avoid flaps. That is, they help ensure that you start sending RTP packets initially from the place where you are likely to receive them. There is no guarantee, so its really an optimization of sorts, which is why I put it at SHOULD strength. Comments on this algorithm? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.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 Mon Nov 8 08:47:31 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 IAA07200 for ; Mon, 8 Nov 2004 08:47:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9sM-0000xn-IC for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 08:48:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9gl-000157-TB; Mon, 08 Nov 2004 08:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8fE-0008P5-UE for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 07:30:28 -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 HAA28056 for ; Mon, 8 Nov 2004 07:30:27 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8fk-0006wC-PY for mmusic@ietf.org; Mon, 08 Nov 2004 07:31:02 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA8CTOX09833; Mon, 8 Nov 2004 14:29:24 +0200 Date: Mon, 8 Nov 2004 14:29:24 +0200 (EET) From: Pekka Savola To: Hoerdt Mickael In-Reply-To: <418F40C7.7000800@clarinet.u-strasbg.fr> Message-ID: References: <20041104154408.GA15370@1-4-5.net> <418F40C7.7000800@clarinet.u-strasbg.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 08 Nov 2004 08:36:06 -0500 Cc: David Meyer , mmusic@ietf.org, csp@csperkins.org, mboned@lists.uoregon.edu Subject: [MMUSIC] ASM-like SSM [Re: mboned: updated MBONED agenda 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: 8abaac9e10c826e8252866cbe6766464 On Mon, 8 Nov 2004, Hoerdt Mickael wrote: > I am happy to see that multi-source SSM session layering is still a > potential working topic at the IETF. I continued my work, but mainly > on the implementation (the API changed) and finally named the very > simple protocol that I presented here more than one year ago : > Source Specific Multicast Source Discovery Protocol (SSMSDP). It > still uses a shared SSM tree to signal new channels presents in the > session. Source announcements toward the root of the tree can use > TCP or UDP (see the API doc), but are not MSDP formated as in Rami > lethonen work. What's more, using SSMSDP approach likely avoids the IPR concerns about a patent application on mroutessm-01. The problem here is about where the work can move forward. multissm could be done here, which is why some might see it more feasible; an application effort might get more resistance from app folks, while it might be in some other ways a better approach. >> - Dynamic Multi-Source Discovery for SSM using MSDP 10 minutes >> draft-lehtonen-mboned-multissm-01.txt >> Lehtonen -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 8 08:48: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 IAA07557 for ; Mon, 8 Nov 2004 08:48:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9tg-00013C-0L for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 08:49:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9rV-0003RA-Of; Mon, 08 Nov 2004 08:47:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR9XA-0007oW-AB for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 08:26:13 -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 IAA04741 for ; Mon, 8 Nov 2004 08:26:10 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR9Xg-0000EO-9a for mmusic@ietf.org; Mon, 08 Nov 2004 08:26:46 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2004 05:39:11 -0800 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA8DPXom001206; Mon, 8 Nov 2004 05:25:34 -0800 (PST) Received: from [130.129.135.140] (sjc-vpn2-81.cisco.com [10.21.112.81]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFP05019; Mon, 8 Nov 2004 05:25:35 -0800 (PST) Message-ID: <418F73CE.4070009@cisco.com> Date: Mon, 08 Nov 2004 08:25:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ml-mmusic@ringle.org Subject: Re: [MMUSIC] ICE Call setup latency References: <200410271542.47623.ml-mmusic@ringle.org> In-Reply-To: <200410271542.47623.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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Sorry for the delay, Jon. Inline. Jon Ringle wrote: > The -03 ICE draft in Figure 2, shows the Accept message occuring before the > STUN checks are performed. The responder can perform them immediately (i.e. 4 and 5 can happen in parallel). However, Message 4 has to arrive before message 5 can be successful. Obviously, message 6 has to happen after message 4. > I believe that this is because the STUN checks > can't be performed until both the Initiator and Responder have created their > connection tables. Right. However the Accept message seems to imply that the user > has accepted the call. Accept corresponds to an answer as defined in RFC 3264. That doesn't have to come in a SIP 200 OK; it could come in a 183. 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. This is called post-pickup delay. If you do send the SDP answer in the 200 OK, the post-pickup delay is increased by a STUN RTT. That is, after the 200 OK, it has to wait for a STUN request and response before it can send media. Those RTT are e2e, unlike the signaling. Thus, it is not too bad. Sending the SDP in the 183 would make the post-pickup delay zero. > > 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. What needs to change is that the section on mapping ICE into SIP/SDP has to clarify that the answer can come in a 18x, and that doing so is a good idea from a post-pickup perspective. I'll make that change. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.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 Mon Nov 8 10:00: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 KAA15864 for ; Mon, 8 Nov 2004 10:00:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRB1K-0003H7-0t for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 10:01:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAqA-0001Zw-TP; Mon, 08 Nov 2004 09:49:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAYr-0005rG-S0 for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 09:32:01 -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 JAA12542 for ; Mon, 8 Nov 2004 09:31:59 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAZP-0002Nv-Fo for mmusic@ietf.org; Mon, 08 Nov 2004 09:32:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 08 Nov 2004 06:45:02 -0800 X-BrightmailFiltered: true Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iA8EVQcp000824; Mon, 8 Nov 2004 06:31:26 -0800 (PST) Received: from jmpolk-w2k01.diablo.cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA23203; Mon, 8 Nov 2004 06:31:26 -0800 (PST) Message-Id: <4.3.2.7.2.20041108082500.0273c7b8@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 08:31:30 -0600 To: mmusic@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Gonzalo Camarillo Subject: [MMUSIC] Connection-Establishment Preconditions question 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.1 (+) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Shouldn't the example in draft-ietf-mmusic-connection-precon-00.txt be taken through the message flow point that the attribute lines are: a=curr e2e sendrecv a=des e2e mandatory sendrecv for clarity? cheers, James ******************* Truth is not to be argued... it is to be presented _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 8 10:40: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 KAA21449 for ; Mon, 8 Nov 2004 10:40:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRBe6-0004VX-4U for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 10:41:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRBP2-0000RU-Ew; Mon, 08 Nov 2004 10:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAr9-00025s-TM for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 09:50:56 -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 JAA14871 for ; Mon, 8 Nov 2004 09:50:53 -0500 (EST) From: rami.lehtonen@teliasonera.com Received: from floor.dave.sonera.fi ([131.177.130.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRArf-00030W-3Q for mmusic@ietf.org; Mon, 08 Nov 2004 09:51:30 -0500 Received: from floor.dave.sonera.fi (localhost [127.0.0.1]) by floor.dave.sonera.fi (Sendmail) with ESMTP id iA8EoffX009168 for ; Mon, 8 Nov 2004 16:50:43 +0200 (EET) Received: from FITMS200MB.tcad.telia.se (fitms200cb.tcad.telia.se [131.177.121.202]) by floor.dave.sonera.fi (Sendmail) with ESMTP id iA8EodDi009165; Mon, 8 Nov 2004 16:50:40 +0200 (EET) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2004 16:50:38 +0200 Message-ID: <6A0EBD2F1250D142BDCC95819153F6BE1C48AF@FITMS200MB.tcad.telia.se> Thread-Topic: ASM-like SSM [Re: mboned: updated MBONED agenda for IETF 61] Thread-Index: AcTFkcgQ3j1ee85MQbi5CPcPHQ3zcAADpTnw To: , X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 08 Nov 2004 10:25:55 -0500 Cc: dmm@1-4-5.net, mmusic@ietf.org, csp@csperkins.org, mboned@lists.uoregon.edu Subject: [MMUSIC] RE: ASM-like SSM [Re: mboned: updated MBONED agenda 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.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: owner-mboned@lists.uoregon.edu > [mailto:owner-mboned@lists.uoregon.edu]On Behalf Of Pekka Savola > > On Mon, 8 Nov 2004, Hoerdt Mickael wrote: > > I am happy to see that multi-source SSM session layering is still a=20 > > potential working topic at the IETF. I continued my work,=20 > but mainly=20 > > on the implementation (the API changed) and finally named the very=20 > > simple protocol that I presented here more than one year ago :=20 > > Source Specific Multicast Source Discovery Protocol (SSMSDP). It=20 > > still uses a shared SSM tree to signal new channels presents in the=20 > > session. Source announcements toward the root of the tree can use=20 > > TCP or UDP (see the API doc), but are not MSDP formated as in Rami=20 > > lethonen work. >=20 > What's more, using SSMSDP approach likely avoids the IPR concerns=20 > about a patent application on mroutessm-01. >=20 > The problem here is about where the work can move forward. multissm=20 > could be done here, which is why some might see it more feasible; an=20 > application effort might get more resistance from app folks, while it=20 > might be in some other ways a better approach. While the multissm work can be done also totally on the application = layer, it is important to notice that network level (RP like) support is = needed in some cases to guarantee availability and redundancy for the = source discovery. This makes the standardisation of host level source = discovery important. Still there are many common goals/ideas with Mickael's source discovery = and multissm, so perhaps we should look for one common solution for the = end-host source discovery. - Rami _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 8 15:27: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 PAA26185 for ; Mon, 8 Nov 2004 15:27:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRG7I-0004aT-KG for mmusic-web-archive@ietf.org; Mon, 08 Nov 2004 15:27:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFoT-0000ca-IQ; Mon, 08 Nov 2004 15:08:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRFbs-0007Kp-53 for mmusic@megatron.ietf.org; Mon, 08 Nov 2004 14:55:28 -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 OAA21537 for ; Mon, 8 Nov 2004 14:55:26 -0500 (EST) Received: from sightspeed.com ([65.241.182.65]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRFcT-0003f8-76 for mmusic@ietf.org; Mon, 08 Nov 2004 14:56:05 -0500 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; Mon, 08 Nov 2004 11:55:19 -0800 id 00001BCC.418FCF28.000074E9 Message-ID: <418FCF24.9070006@sightspeed.com> Date: Mon, 08 Nov 2004 11:55:16 -0800 From: Aron Rosenberg Organization: SightSpeed Inc. User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Clarification about ICE Management of Resources 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: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Have we considered making the use of symmetric RTP mandatory or suggested with ICE? Wouldn't that solve numerous of these corner case issues? Aside from that, the algorithm suggested below works quite well to fix the keep alive problem mentioned. -Aron Rosenberg >This is an excellent point, thank you for pointing it out. It is a >definite problem in the specification, since right now those keepalives >are not happening. > >What needs to happen is that you end up with a symmetric relationship, >where both sides send to, and receive from, the same address. As such, >you need to add an algorithm to the spec to select the source address in >a much more deterministic way. I'd suggest that the following algorithm >works: > >A client MUST send from the transport address on which it most recently >received an RTP packet. If there is no such address (as no RTP packets >are being received yet), it SHOULD send from the transport address of >highest local priority on which a STUN connectivity check has been >received. If there is no such address (as no connectivity checks have >been received yet), it SHOULD send from the local transport address of >highest priority. > > > >The first sentence of this paragraph achieves the desired effect - it >will force media to be sent from the same port on which it is being >received. The remaining sentences help avoid flaps. That is, they help >ensure that you start sending RTP packets initially from the place where >you are likely to receive them. There is no guarantee, so its really an >optimization of sorts, which is why I put it at SHOULD strength. >Comments on this algorithm? > >Thanks, >Jonathan R. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Wed Nov 10 17:05: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 RAA09912 for ; Wed, 10 Nov 2004 17:05:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0bG-0000M6-3l for mmusic-web-archive@ietf.org; Wed, 10 Nov 2004 17:06:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0Pw-0003j2-Cz; Wed, 10 Nov 2004 16:54:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0Id-000870-LP for mmusic@megatron.ietf.org; Wed, 10 Nov 2004 16:46:45 -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 QAA08328 for ; Wed, 10 Nov 2004 16:46:41 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0JP-0008L6-7b for mmusic@ietf.org; Wed, 10 Nov 2004 16:47:48 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAALkPR2011297 for ; Wed, 10 Nov 2004 22:46:25 +0100 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 22:46:25 +0100 Received: from [147.214.97.152] (RESEARCH-1FD0E1 [147.214.97.152]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WFZ2SH35; Wed, 10 Nov 2004 22:46:24 +0100 Message-ID: <41928C2E.5000709@ericsson.com> Date: Wed, 10 Nov 2004 22:46:22 +0100 X-Sybari-Trust: 6764c4a7 ad48f3dd bd38502a 00000179 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 , "mmusic (E-mail)" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2004 21:46:25.0085 (UTC) FILETIME=[B9CE46D0:01C4C76E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Transport header protocol/profile/lower-layer ABNF 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 Hi, > > I would also suggest that we modify the BNF to reflect the fact that the > "profile" makes sense with RTP and not necessarily with other proprietary > transport protocols. > > Current syntax: > 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 > > We could modify the BNF so that everything remains the same for RTP, but > for other transport protocols, we could make the "profile" optional. > > Proposed: > transport-id = [ rtp-trans | other-trans ] > ; no LWS is allowed inside transport-id > rtp-trans = "RTP" "/" profile ["/" lower-transport] > ; no LWS is allowed inside transport-id > profile = "AVP" / token > lower-transport = "TCP" / "UDP" / token > > other-trans = token [ "/" token ]* > I assume that you mean to have other-trans = token *("/" token) I think that this is maybe not a bad idea as it seems more general. It however seem to have an interoperability issue as a old receiver could throw up over the lack of a "/" after the first token. More input on this question is appropriate. 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 Nov 10 17:06: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 RAA10149 for ; Wed, 10 Nov 2004 17:06:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0cb-0000Ps-GY for mmusic-web-archive@ietf.org; Wed, 10 Nov 2004 17:07:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0QD-0003rR-U1; Wed, 10 Nov 2004 16:54:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0Kq-0000gB-S2 for mmusic@megatron.ietf.org; Wed, 10 Nov 2004 16:49:01 -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 QAA08512 for ; Wed, 10 Nov 2004 16:48:58 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0Lq-0008PM-JT for mmusic@ietf.org; Wed, 10 Nov 2004 16:50:05 -0500 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 iAALmuvD017872 for ; Wed, 10 Nov 2004 22:48:56 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Nov 2004 22:48:55 +0100 Received: from [147.214.97.152] (RESEARCH-1FD0E1 [147.214.97.152]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVVNXH7; Wed, 10 Nov 2004 22:48:55 +0100 Message-ID: <41928CC6.5050005@ericsson.com> Date: Wed, 10 Nov 2004 22:48:54 +0100 X-Sybari-Trust: 1e4971e7 bfd556f1 425c8a31 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.20041105125151.08b14550@mailone.real.com> In-Reply-To: <6.1.2.0.2.20041105125151.08b14550@mailone.real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2004 21:48:55.0192 (UTC) FILETIME=[1346C980:01C4C76F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Rishi Mathew wrote: > > This looks right... but does it mean that if there is a "MUST understand" > parameter in a transport that I want to ignore, I have to send back an > error? > > For example, > Transport: > x-real-rdt/udp;client_port=6970;mode=play;spec_par="xyz";mand="spec_par",RTP/AVP/UDP;client_port=6970;mode=play > > > > Lets assume a server does not understand RDT. Preferably, it should just > ignore everything until the next "transport" and start from there. But, > since there is a mandatory parameter in a transport that it does not > understand, will it be forced to return an error? > > >Further suggestions or comments? Sean Sheedy made a very good suggestion to me in a hallway discussion. A simpler rule that makes this easier to handle would be to change the rule to: A receiver MAY ignore any transport specification, but MUST understand all parameters within any specification it selects to use. That way one has a very simple rule, and in cases where one has parameter that could be ignored, one can simply offer one transport spec with the parameter and another without. I don't think this will result in a huge number of specifications. What do people think about it? 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 Nov 11 21:51: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 VAA29894 for ; Thu, 11 Nov 2004 21:51:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSRYN-0004YF-CZ for mmusic-web-archive@ietf.org; Thu, 11 Nov 2004 21:52:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSRWA-0008H5-Me; Thu, 11 Nov 2004 21:50:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSRSQ-0007nW-0B for mmusic@megatron.ietf.org; Thu, 11 Nov 2004 21:46:38 -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 VAA29737 for ; Thu, 11 Nov 2004 21:46:36 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSRTe-0004Uj-Td for mmusic@ietf.org; Thu, 11 Nov 2004 21:47:58 -0500 Received: from ci0026exch001u.wins.lucent.com (h135-252-18-18.lucent.com [135.252.18.18]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAC2kVJP018614 for ; Thu, 11 Nov 2004 20:46:32 -0600 (CST) Received: by CI0026EXCH001U with Internet Mail Service (5.5.2657.72) id <4Y5CMN92>; Fri, 12 Nov 2004 10:46:30 +0800 Message-ID: <31C0F08B0D18D511ACC800508BAE7B470C1A830C@CI0026EXCH001U> From: "Fan, Chen (Chen)" To: mmusic@ietf.org Date: Fri, 12 Nov 2004 10:46:29 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="gb2312" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MMUSIC] What is the necessity for using RTP/UDP instead of HTTP/TCP to tr ansmit video content? 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: 9182cfff02fae4f1b6e9349e01d62f32 Folks, Maybe this is a very naive question, but when I was asked this question, I don't think I have many strong reasons. One benefit of using RTP/UDP is the synchronization capability, but we can also insert timestamps into the HTTP packets to realize the synchronization. The other benefit of using RTP/UDP is that UDP does not impose any repeat transmission, which can reduce the network overhead. However, to guarantee the end2end video transmission quality, usually the application layer will use the repeat transmission mechanism in some cases. In addition, to penetrate the firewalls, HTTP tunnel is usually used to encapsulate the RTP packets, so, why don't we just use HTTP for video streaming? I don't see any stop signs on this way... Best regards Chen _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Nov 12 10:13:45 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 KAA10783 for ; Fri, 12 Nov 2004 10:13:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSd8r-0002Jo-Mv for mmusic-web-archive@ietf.org; Fri, 12 Nov 2004 10:15:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSd4i-0003gJ-Ax; Fri, 12 Nov 2004 10:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSczP-0001CS-If for mmusic@megatron.ietf.org; Fri, 12 Nov 2004 10:05:27 -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 KAA09376 for ; Fri, 12 Nov 2004 10:05:25 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSd0m-00024w-UP for mmusic@ietf.org; Fri, 12 Nov 2004 10:06:54 -0500 Received: from [130.129.135.72] (port=55139 helo=[130.129.135.72]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CScyt-0000KJ-1X; Fri, 12 Nov 2004 15:04:55 +0000 In-Reply-To: <31C0F08B0D18D511ACC800508BAE7B470C1A830C@CI0026EXCH001U> References: <31C0F08B0D18D511ACC800508BAE7B470C1A830C@CI0026EXCH001U> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <329EB3BC-34BC-11D9-8623-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] What is the necessity for using RTP/UDP instead of HTTP/TCP to tr ansmit video content? Date: Fri, 12 Nov 2004 10:04:49 -0500 To: "Fan, Chen (Chen)" X-Mailer: Apple Mail (2.619) 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 [This is really a question for the AVT working group] On 11 Nov 2004, at 21:46, Fan, Chen (Chen) wrote: > Maybe this is a very naive question, but when I was asked this > question, I > don't think I have many strong reasons. > > One benefit of using RTP/UDP is the synchronization capability, but we > can > also insert timestamps into the HTTP packets to realize the > synchronization. > > > The other benefit of using RTP/UDP is that UDP does not impose any > repeat > transmission, which can reduce the network overhead. However, to > guarantee > the end2end video transmission quality, usually the application layer > will > use the repeat transmission mechanism in some cases. > > In addition, to penetrate the firewalls, HTTP tunnel is usually used to > encapsulate the RTP packets, so, why don't we just use HTTP for video > streaming? I don't see any stop signs on this way... Inappropriate congestion response and retransmission behaviour are the most obvious reasons, especially for applications with a requirement for low end to end latency. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Nov 12 19:49: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 TAA16320 for ; Fri, 12 Nov 2004 19:49:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSm8E-0001c2-3I for mmusic-web-archive@ietf.org; Fri, 12 Nov 2004 19:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm5L-0002vh-9o; Fri, 12 Nov 2004 19:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm4d-0002fV-U4 for mmusic@megatron.ietf.org; Fri, 12 Nov 2004 19:47:27 -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 TAA16177 for ; Fri, 12 Nov 2004 19:47:26 -0500 (EST) Received: from mulder.f5.com ([205.229.151.150] helo=exchfour.olympus.f5net.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSm64-0001Sl-9N for mmusic@ietf.org; Fri, 12 Nov 2004 19:48:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Nov 2004 16:47:22 -0800 Message-ID: <3D8E54E3CAA3864295233C618F53F2AD82EFF5@exchfour.olympus.f5net.com> Thread-Topic: RTSP session identifiers Thread-Index: AcTJGlZEjw4CbT3OTJqsMEqEreQD1w== From: "Mark Crosland" To: X-Spam-Score: 0.2 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Subject: [MMUSIC] RTSP session identifiers 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="===============1984887608==" Sender: mmusic-bounces@ietf.org Errors-To: mmusic-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 This is a multi-part message in MIME format. --===============1984887608== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C91A.568C8841" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4C91A.568C8841 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, =20 I have a question regarding RTSP session IDs that perhaps someone would answer. =20 RFC 2326 indicates that an RTSP session identifier is not tied to a single TCP connection or some well-defined set of UDP packets (1.1, 1.7, 12.37, 16 session hijacking). =20 I am curious as to what a use-case or two might be where a session ID spans multiple TCP connections to the server? I'm guessing here, but would they revolve around conferencing? =20 For the generic video/audio user on the internet I assume that when they exit out of something like real player or windows media player, that the server stops streaming data to them, and the chances of them reconnecting to the server and resuming where they left off are slim. But perhaps that is only because the clients don't support that mode of operation, i.e., saving RTSP session IDs, reconnecting to a server and resuming the data stream. =20 Do most media clients and servers out there support session management across multiple control channels? =20 Thanks, Mark Crosland ------_=_NextPart_001_01C4C91A.568C8841 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have a question regarding RTSP session IDs that = perhaps someone would answer.

 

RFC 2326 indicates that an RTSP session identifier is = not tied to a single TCP connection or some well-defined = set

of UDP packets (1.1, 1.7, 12.37, 16 session = hijacking).

 

I am curious as to what a use-case or two might be = where a session ID spans multiple TCP connections to the server? I’m = guessing here, but would they revolve around = conferencing?

 

For the generic video/audio user on the internet I = assume that when they exit out of something like real player or windows media = player, that the server stops streaming data to them, and the chances of them = reconnecting to the server and resuming where they left off are slim. But perhaps = that is only because the clients don’t support that mode of operation, = i.e., saving RTSP session IDs, reconnecting to a server and resuming the data = stream.

 

Do most media clients and servers out there support = session management across multiple control = channels?

 

Thanks,

Mark Crosland

------_=_NextPart_001_01C4C91A.568C8841-- --===============1984887608== 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 --===============1984887608==-- From mmusic-bounces@ietf.org Fri Nov 12 19:53:11 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 TAA16681 for ; Fri, 12 Nov 2004 19:53:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSmBg-0001mx-Fn for mmusic-web-archive@ietf.org; Fri, 12 Nov 2004 19:54:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm85-0003WK-OS; Fri, 12 Nov 2004 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm6j-0003AJ-Vr for mmusic@megatron.ietf.org; Fri, 12 Nov 2004 19:49:38 -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 TAA16317 for ; Fri, 12 Nov 2004 19:49:36 -0500 (EST) Received: from flawless.real.com ([207.188.23.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSm8D-0001be-7a for mmusic@ietf.org; Fri, 12 Nov 2004 19:51:09 -0500 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; Fri, 12 Nov 2004 16:48:59 -0800 Message-Id: <6.1.2.0.2.20041112164439.0585d000@mailone.real.com> X-Sender: rmathew@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 12 Nov 2004 16:47:13 -0800 To: Magnus Westerlund , "mmusic (E-mail)" From: Rishi Mathew In-Reply-To: <41928C2E.5000709@ericsson.com> References: <41928C2E.5000709@ericsson.com> 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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Transport header protocol/profile/lower-layer ABNF 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 Magnus, Comment inline... At 01:46 PM 11/10/2004, Magnus Westerlund wrote: >Hi, > > > > > I would also suggest that we modify the BNF to reflect the fact that the > > "profile" makes sense with RTP and not necessarily with other proprietary > > transport protocols. > > > > Current syntax: > > 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 > > > > We could modify the BNF so that everything remains the same for RTP, but > > for other transport protocols, we could make the "profile" optional. > > > > Proposed: > > transport-id = [ rtp-trans | other-trans ] > > ; no LWS is allowed inside transport-id > > rtp-trans = "RTP" "/" profile ["/" lower-transport] > > ; no LWS is allowed inside transport-id > > profile = "AVP" / token > > lower-transport = "TCP" / "UDP" / token > > > > other-trans = token [ "/" token ]* > > > >I assume that you mean to have >other-trans = token *("/" token) Yes. Basically, any number of tokens separated by a "/" Thanks, Rishi. >I think that this is maybe not a bad idea as it seems more general. It >however seem to have an interoperability issue as a old receiver could >throw up over the lack of a "/" after the first token. > >More input on this question is appropriate. >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 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 Fri Nov 12 19:54:28 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 TAA16762 for ; Fri, 12 Nov 2004 19:54:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSmCv-0001ol-6Z for mmusic-web-archive@ietf.org; Fri, 12 Nov 2004 19:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm86-0003WP-3R; Fri, 12 Nov 2004 19:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSm6t-0003AP-PQ for mmusic@megatron.ietf.org; Fri, 12 Nov 2004 19:49:47 -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 TAA16341 for ; Fri, 12 Nov 2004 19:49:46 -0500 (EST) Received: from flawless.real.com ([207.188.23.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSm8M-0001be-GA for mmusic@ietf.org; Fri, 12 Nov 2004 19:51:19 -0500 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; Fri, 12 Nov 2004 16:49:40 -0800 Message-Id: <6.1.2.0.2.20041112164720.05a53f48@mailone.real.com> X-Sender: rmathew@mailone.real.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 12 Nov 2004 16:47:56 -0800 To: Magnus Westerlund From: Rishi Mathew Subject: Re: [MMUSIC] Transport Header Stipulation In-Reply-To: <41928CC6.5050005@ericsson.com> References: <6.1.2.0.2.20041105125151.08b14550@mailone.real.com> <41928CC6.5050005@ericsson.com> 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: f4c2cf0bccc868e4cc88dace71fb3f44 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: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Magnus, Comments inline.. At 01:48 PM 11/10/2004, Magnus Westerlund wrote: >Rishi Mathew wrote: > >>This looks right... but does it mean that if there is a "MUST understand" >>parameter in a transport that I want to ignore, I have to send back an error? >>For example, >>Transport: >>x-real-rdt/udp;client_port=6970;mode=play;spec_par="xyz";mand="spec_par",RTP/AVP/UDP;client_port=6970;mode=play >> >> >>Lets assume a server does not understand RDT. Preferably, it should just >>ignore everything until the next "transport" and start from there. But, >>since there is a mandatory parameter in a transport that it does not >>understand, will it be forced to return an error? >> >Further suggestions or comments? > >Sean Sheedy made a very good suggestion to me in a hallway discussion. A >simpler rule that makes this easier to handle would be to change the rule to: > >A receiver MAY ignore any transport specification, but MUST understand all >parameters within any specification it selects to use. > >That way one has a very simple rule, and in cases where one has parameter >that could be ignored, one can simply offer one transport spec with the >parameter and another without. I don't think this will result in a huge >number of specifications. > >What do people think about it? I think this is a good idea and simplifies the spec to a great extent. Thanks, Rishi. >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 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 Nov 16 10:40: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 KAA10945 for ; Tue, 16 Nov 2004 10:40:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5Tm-0008P0-1F for mmusic-web-archive@ietf.org; Tue, 16 Nov 2004 10:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5Nj-0004pV-Ep; Tue, 16 Nov 2004 10:36:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5AQ-0002UR-UP for mmusic@megatron.ietf.org; Tue, 16 Nov 2004 10:22:50 -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 KAA07853 for ; Tue, 16 Nov 2004 10:22:49 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5CR-0007yP-34 for mmusic@ietf.org; Tue, 16 Nov 2004 10:25:09 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAGFMYR2002096 for ; Tue, 16 Nov 2004 16:22:34 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 16 Nov 2004 16:22:34 +0100 Received: from ericsson.com (research-64de67.ki.sw.ericsson.se [147.214.118.190]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVWYBYW; Tue, 16 Nov 2004 16:22:33 +0100 Message-ID: <419A1B39.9000105@ericsson.com> Date: Tue, 16 Nov 2004 16:22:33 +0100 X-Sybari-Trust: d2445c78 bfd556f1 22ce5d73 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: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2004 15:22:34.0105 (UTC) FILETIME=[18C01E90:01C4CBF0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: jon.peterson@neustar.biz Subject: [MMUSIC] Key mgmt extensions 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 Dear all, Roughly 1-2 weeks ago there was a discussion thread on this list concerning possible security problems with offering several key mgmt options in draft-ietf-mmusic-kmgmt-ext-11.txt We have since had some discussion with Martin and Steffen, and we have come to an agreement that we do not see any security issues, but would anyway like to add the following text to clarify the intention of the mechanism: "Note that the multiple offer option has been added to optimize signaling overhead in case the Initiator knows some key (e.g. a public key) that the Responder has, but is unsure of what protocol the Responder supports. The mechanism is not intended to negotiate options within one and the same protocol." Even if there are no security problems, we want to avoid overly complex uses of the mechanism, e.g. it could be used to duplicate functionality that is anyway already present in some key mgmt protocol, and create multiple ways of doing the same thing. A new draft will submitted with this text included. Best, /Mats _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 16 13:46: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 NAA28783 for ; Tue, 16 Nov 2004 13:46:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8Nm-0004e1-K0 for mmusic-web-archive@ietf.org; Tue, 16 Nov 2004 13:48:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU85U-0003C5-Qs; Tue, 16 Nov 2004 13:29:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU816-00024d-6u for mmusic@megatron.ietf.org; Tue, 16 Nov 2004 13:25:25 -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 NAA26916 for ; Tue, 16 Nov 2004 13:25:21 -0500 (EST) 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 1CU83J-00047n-8Y for mmusic@ietf.org; Tue, 16 Nov 2004 13:27:43 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 10:37:49 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAGIOh3O028374; Tue, 16 Nov 2004 10:24:44 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT78503; Tue, 16 Nov 2004 10:24:44 -0800 (PST) Message-ID: <419A45EC.2020400@cisco.com> Date: Tue, 16 Nov 2004 13:24:44 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aron@sightspeed.com Subject: Re: [MMUSIC] Re: Clarification about ICE Management of Resources References: <418FCF24.9070006@sightspeed.com> In-Reply-To: <418FCF24.9070006@sightspeed.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Symmetric RTP will basically be what you get with the behavior below. As such, it is effectively mandatory as an implicit by-product of the algorithm below. -Jonathan R. Aron Rosenberg wrote: > Have we considered making the use of symmetric RTP mandatory or > suggested with ICE? Wouldn't that solve numerous of these corner case > issues? Aside from that, the algorithm suggested below works quite well > to fix the keep alive problem mentioned. > > -Aron Rosenberg > >> This is an excellent point, thank you for pointing it out. It is a >> definite problem in the specification, since right now those >> keepalives are not happening. >> >> What needs to happen is that you end up with a symmetric relationship, >> where both sides send to, and receive from, the same address. As such, >> you need to add an algorithm to the spec to select the source address >> in a much more deterministic way. I'd suggest that the following >> algorithm works: >> >> A client MUST send from the transport address on which it most >> recently received an RTP packet. If there is no such address (as no >> RTP packets are being received yet), it SHOULD send from the transport >> address of highest local priority on which a STUN connectivity check >> has been received. If there is no such address (as no connectivity >> checks have been received yet), it SHOULD send from the local >> transport address of highest priority. >> >> >> >> The first sentence of this paragraph achieves the desired effect - it >> will force media to be sent from the same port on which it is being >> received. The remaining sentences help avoid flaps. That is, they help >> ensure that you start sending RTP packets initially from the place >> where you are likely to receive them. There is no guarantee, so its >> really an optimization of sorts, which is why I put it at SHOULD >> strength. >> Comments on this algorithm? >> >> Thanks, >> Jonathan R. >> >> > > _______________________________________________ > 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@cisco.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 Nov 16 13:47:12 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 NAA28896 for ; Tue, 16 Nov 2004 13:47:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8OR-0004fY-Tg for mmusic-web-archive@ietf.org; Tue, 16 Nov 2004 13:49:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU869-0003LK-B0; Tue, 16 Nov 2004 13:30:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU84A-0002lQ-Qk for mmusic@megatron.ietf.org; Tue, 16 Nov 2004 13:28:35 -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 NAA27154 for ; Tue, 16 Nov 2004 13:28:31 -0500 (EST) 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 1CU86P-0004C4-1x for mmusic@ietf.org; Tue, 16 Nov 2004 13:30:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 10:41:02 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAGIRw3O000882; Tue, 16 Nov 2004 10:27:58 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn4-1387.cisco.com [10.21.85.106]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AFT78774; Tue, 16 Nov 2004 10:27:57 -0800 (PST) Message-ID: <419A46AC.7090506@cisco.com> Date: Tue, 16 Nov 2004 13:27:56 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 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> <417FDBAD.5070903@dynamicsoft.com> <41801CA5.6060604@i2telecom.com> In-Reply-To: <41801CA5.6060604@i2telecom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit inline. Awais Ali wrote: >> 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. This was discussed at the IETF meeting last week. The conclusion was that there remained sufficient compelling reasons to avoid the usage of so many sockets. As such, the next revision of the draft (which I promised to complete this week) will allow for the currently documented 1-1 case, and a 1-many case. In the 1-many case, the usage of a timer as you suggest can be used. It will be an implementation choice as to which approach is used; both interoperate. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.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 Nov 23 13:41:26 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 NAA07216 for ; Tue, 23 Nov 2004 13:41:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWffB-0008M2-QR for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 13:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfTX-0007mx-86; Tue, 23 Nov 2004 13:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWfOo-0006dh-U7 for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 13:28:22 -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 NAA06279 for ; Tue, 23 Nov 2004 13:28:19 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWfSW-0006bL-Kz for mmusic@ietf.org; Tue, 23 Nov 2004 13:32:13 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iANISCGn014552 for ; Tue, 23 Nov 2004 18:28:12 GMT Received: from [152.78.64.103] (hwickabab [152.78.64.103]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id SAA02641 for ; Tue, 23 Nov 2004 18:28:10 GMT Mime-Version: 1.0 X-Sender: njh@imap.ecs.soton.ac.uk (Unverified) Message-Id: Date: Tue, 23 Nov 2004 18:28:09 +0000 To: mmusic@ietf.org From: Nicholas Humfrey Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: njh@ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [MMUSIC] SDP description for HTTP/RTSP streams 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 Hi, I have been trawling the web to see if there is an official way to describe a RTSP/HTTP (URI) stream using SDP. I have seen some SDP descriptions that put 'http' into the transport in m=, the server in c=, and the path as an attribute. Has there been any Internet draft to standardize this ? I have mixed feelings about it - half of me thinks it is 'wrong' and there are better ways of describing these types of (evil ;-) shoutcast/icecast streams as URIs (M3U, PLS). But the other half of me thinks it would be nice to be able to describe all types of media streams using SDP and announce them over SAP. And store them in a common format in directories of streams. nick. PS. Advertisement for my two perl modules: http://search.cpan.org/~njh/Net-SAP/ http://search.cpan.org/~njh/Net-SDP/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 23 14: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 OAA10487 for ; Tue, 23 Nov 2004 14:23:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgJl-0005ba-2Q for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 14:27:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgD3-000883-8y; Tue, 23 Nov 2004 14:20:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWg7x-0007HQ-R7 for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 14:15:02 -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 OAA09832 for ; Tue, 23 Nov 2004 14:14:59 -0500 (EST) Received: from flawless.real.com ([207.188.23.141]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgBg-0004PX-2z for mmusic@ietf.org; Tue, 23 Nov 2004 14:18:52 -0500 Received: from 172.22.137.230 ([::ffff:172.22.137.230]) (AUTH: LOGIN robla, SSL: TLSv1/SSLv3,128bits,RC4-MD5) by flawless.real.com with esmtp; Tue, 23 Nov 2004 11:14:26 -0800 Subject: Re: [MMUSIC] SDP description for HTTP/RTSP streams From: Rob Lanphier To: Nicholas Humfrey In-Reply-To: References: Organization: RealNetworks Date: Tue, 23 Nov 2004 11:12:20 -0800 Message-Id: <1101237140.3852.23.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Evolution 2.0.2 (2.0.2-3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: robla@real.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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi Nick, I'll leave it to others to describe the current status for various specifications for this, since I'm very rusty on things. The RTSP specification itself describes how to do this for RTSP. Additionally, I wrote a draft for how to do this with HTTP which was fairly well received, but the motivation for pushing it forward was fleeting. Here's the spec: http://www.dmn.tzi.org/ietf/mmusic/53/id/draft-lanphier-radplay-00.txt If you'd like to pick up the torch and carry it forward, modifying it as appropriate, I'd be happy to hand it off to you. Rob On Tue, 2004-11-23 at 18:28 +0000, Nicholas Humfrey wrote: > Hi, > > > I have been trawling the web to see if there is an official way to > describe a RTSP/HTTP (URI) stream using SDP. > > I have seen some SDP descriptions that put 'http' into the transport > in m=, the server in c=, and the path as an attribute. > > > Has there been any Internet draft to standardize this ? > > > I have mixed feelings about it - half of me thinks it is 'wrong' and > there are better ways of describing these types of (evil ;-) > shoutcast/icecast streams as URIs (M3U, PLS). > > But the other half of me thinks it would be nice to be able to > describe all types of media streams using SDP and announce them over > SAP. And store them in a common format in directories of streams. > > > > nick. > > > > PS. Advertisement for my two perl modules: > > http://search.cpan.org/~njh/Net-SAP/ > http://search.cpan.org/~njh/Net-SDP/ > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Rob Lanphier, Development Support Manager - RealNetworks Helix Community: http://helixcommunity.org Development Support: http://www.realnetworks.com/products/support/devsupport _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 23 14:37:07 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 OAA11747 for ; Tue, 23 Nov 2004 14:37:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgX6-0007Cu-Ha for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 14:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgO2-00020C-Rh; Tue, 23 Nov 2004 14:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgKZ-0001G5-A0 for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 14:28:03 -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 OAA10862 for ; Tue, 23 Nov 2004 14:28:01 -0500 (EST) Received: from 206-169-193-40.gen.twtelecom.net ([206.169.193.40] helo=ProgressiveComputingLLC.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWgOE-00060p-PU for mmusic@ietf.org; Tue, 23 Nov 2004 14:31:54 -0500 content-class: urn:content-classes:message Subject: RE: [MMUSIC] SDP description for HTTP/RTSP streams Date: Tue, 23 Nov 2004 11:27:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <2D0CA64CDC33E14DA7AB043B8CC4D2BB027451EC@svr-exc.domain.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: [MMUSIC] SDP description for HTTP/RTSP streams Thread-Index: AcTRjBz2gn1goELDQ+a3BbNJI0gMKQABWSig From: "Thomas Gal" To: "Nicholas Humfrey" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Well there's descriptive language in the RTSP document itself. There's an open source implementation at vovida.org you may use as reference. Here's a link to the class information http://www.vovida.org/document/rtsp/rtspstack/RtspSdp.html. -Tom=20 > -----Original Message----- > From: Nicholas Humfrey [mailto:njh@ecs.soton.ac.uk]=20 > Sent: Tuesday, November 23, 2004 10:28 AM > To: mmusic@ietf.org > Subject: [MMUSIC] SDP description for HTTP/RTSP streams >=20 >=20 > Hi, >=20 >=20 > I have been trawling the web to see if there is an official=20 > way to describe a RTSP/HTTP (URI) stream using SDP. >=20 > I have seen some SDP descriptions that put 'http' into the=20 > transport in m=3D, the server in c=3D, and the path as an attribute. >=20 >=20 > Has there been any Internet draft to standardize this ? >=20 >=20 > I have mixed feelings about it - half of me thinks it is 'wrong' and=20 > there are better ways of describing these types of (evil ;-)=20 > shoutcast/icecast streams as URIs (M3U, PLS). >=20 > But the other half of me thinks it would be nice to be able to=20 > describe all types of media streams using SDP and announce them over=20 > SAP. And store them in a common format in directories of streams. >=20 >=20 >=20 > nick. >=20 >=20 >=20 > PS. Advertisement for my two perl modules: >=20 > http://search.cpan.org/~njh/Net-SAP/ > http://search.cpan.org/~njh/Net-SDP/ >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 23 16:05: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 QAA29827 for ; Tue, 23 Nov 2004 16:05:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWhuB-0004tc-5C for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 16:08:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWhBt-0000mU-0M; Tue, 23 Nov 2004 15:23:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWgxB-0007w8-Qj; Tue, 23 Nov 2004 15:07:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17261; Tue, 23 Nov 2004 15:07:55 -0500 (EST) Message-Id: <200411232007.PAA17261@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 23 Nov 2004 15:07:55 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-12.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: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko, et al. Filename : draft-ietf-mmusic-kmgmt-ext-12.txt Pages : 26 Date : 2004-11-23 This document defines general extensions for SDP and RTSP to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the MIKEY key management protocol is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.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-kmgmt-ext-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-11-23142203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-23142203.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 Tue Nov 23 17:02:42 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 RAA11296 for ; Tue, 23 Nov 2004 17:02:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWio0-0005cI-Uo for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 17:06:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiSS-0001zn-4x; Tue, 23 Nov 2004 16:44:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiHj-0002x4-2E for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 16:33:15 -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 QAA05684 for ; Tue, 23 Nov 2004 16:33:12 -0500 (EST) Received: from ns.live.com ([66.80.62.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiLQ-0001HX-DV for mmusic@ietf.org; Tue, 23 Nov 2004 16:37:04 -0500 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.13.1/8.12.11) with ESMTP id iANLX3CQ054327 for ; Tue, 23 Nov 2004 13:33:05 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.13.1/8.12.9/Submit) id iANLX3bF054326; Tue, 23 Nov 2004 13:33:03 -0800 (PST) (envelope-from rsf) Message-Id: <6.2.0.14.1.20041123132739.03227c30@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Nov 2004 13:32:42 -0800 To: mmusic@ietf.org From: Ross Finlayson Subject: RE: [MMUSIC] SDP description for HTTP/RTSP streams In-Reply-To: <2D0CA64CDC33E14DA7AB043B8CC4D2BB027451EC@svr-exc.domain.co m> References: <2D0CA64CDC33E14DA7AB043B8CC4D2BB027451EC@svr-exc.domain.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: 856eb5f76e7a34990d1d457d8e8e5b7f >Well there's descriptive language in the RTSP document itself. I don't think so. The RTSP specification notes that a SDP description for a stream *could* be received using a HTTP "GET", instead of using a RTSP "DESCRIBE". But that's not what Nicholas Humfrey was asking about. I believe he was asking how to describe a HTTP (as opposed to RTP) media stream within SDP. I.e., his question really didn't have anything to do with RTSP. Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 23 17:07: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 RAA11968 for ; Tue, 23 Nov 2004 17:07:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWisz-0006lw-HL for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 17:11:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiTl-0002mF-21; Tue, 23 Nov 2004 16:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWiLx-0006ZL-3M for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 16:37:37 -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 QAA06703 for ; Tue, 23 Nov 2004 16:37:34 -0500 (EST) Received: from ns.live.com ([66.80.62.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiPg-0001wt-Qn for mmusic@ietf.org; Tue, 23 Nov 2004 16:41:29 -0500 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.13.1/8.12.11) with ESMTP id iANLbUBP059643 for ; Tue, 23 Nov 2004 13:37:35 -0800 (PST) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.13.1/8.12.9/Submit) id iANLbU8p059642; Tue, 23 Nov 2004 13:37:30 -0800 (PST) (envelope-from rsf) Message-Id: <6.2.0.14.1.20041123133318.031a0370@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Nov 2004 13:37:19 -0800 To: mmusic@ietf.org From: Ross Finlayson Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [MMUSIC] A comment re. draft-ietf-mmusic-rfc2326bis-06.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: 97adf591118a232206bdb5a27b217034 In section 16.4 ("Live Media Presentation Using Multicast") there's the following "Editor's Note"): Is this example really valid? In what situations does it make sense to do a setup to a multicast distribution channel, and also issue PLAY requests? Please remove this "Editor's Note". As I noted in a message to this mailing list back in August: ------------------------ Why did this even arise as an issue? RTSP *is definitely* useful for playing multicast sessions. In particular, the RTSP "DESCRIBE" command is an excellent way for a client to get the SDP description for a multicast session (even though, in this case, the subsequent "SETUP" and "PLAY" commands turn out to be effectively no-ops). A media player client can play a stream using a "rtsp://" URL, without having to know in advance whether the stream is multicast or unicast. It would be silly to require that a media player use one mechanism for playing multicast streams, and another for playing unicast streams. It baffles me that so many people seem to think that RTSP is for unicast streams only. Please don't perpetuate this myth by removing the multicast example from the spec. Ross (who has implemented and deplayed several multicast streaming applications with built-in RTSP servers) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 23 22:28:12 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 WAA08383 for ; Tue, 23 Nov 2004 22:28:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWnt4-0006I6-8I for mmusic-web-archive@ietf.org; Tue, 23 Nov 2004 22:32:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWno3-0000sI-RJ; Tue, 23 Nov 2004 22:26:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWnmY-0000S8-7k for mmusic@megatron.ietf.org; Tue, 23 Nov 2004 22:25:26 -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 WAA08185 for ; Tue, 23 Nov 2004 22:25:23 -0500 (EST) Received: from mra02.ex.eclipse.net.uk ([212.104.129.89]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWnqK-0005dd-KC for mmusic@ietf.org; Tue, 23 Nov 2004 22:29:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mra02.ex.eclipse.net.uk (Postfix) with ESMTP id 7E824406070 for ; Wed, 24 Nov 2004 03:24:41 +0000 (GMT) Received: from mra02.ex.eclipse.net.uk ([127.0.0.1]) by localhost (mra02.ex.eclipse.net.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13623-01-5 for ; Wed, 24 Nov 2004 03:24:41 +0000 (GMT) Received: from rumdejig.aelius.co.uk (rumdejig.aelius.co.uk [81.168.22.74]) by mra02.ex.eclipse.net.uk (Postfix) with SMTP id 7BA14406211 for ; Wed, 24 Nov 2004 03:24:40 +0000 (GMT) Received: (qmail 12656 invoked from network); 24 Nov 2004 03:25:20 -0000 Received: from unknown (HELO ?10.13.8.10?) (10.13.8.10) by rumdejig.aelius.co.uk with SMTP; 24 Nov 2004 03:25:20 -0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <6.2.0.14.1.20041123132739.03227c30@localhost> References: <2D0CA64CDC33E14DA7AB043B8CC4D2BB027451EC@svr-exc.domain.com> <6.2.0.14.1.20041123132739.03227c30@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77E2BCAC-3DC8-11D9-97B4-000D9357E16C@ecs.soton.ac.uk> Content-Transfer-Encoding: 7bit From: Nicholas J Humfrey Subject: Re: [MMUSIC] SDP description for HTTP streams Date: Wed, 24 Nov 2004 03:25:19 +0000 To: mmusic@ietf.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by Eclipse VIRUSshield at eclipse.net.uk X-Spam-Score: 2.2 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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: 2.2 (++) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Yes Ross is right. Sorry I didn't make it clear what I meant before. Here is an example of a URI to a Icecast stream: http://152.78.104.83:8000/surge-live-high-mp3 And here is a proposed SDP description of that URI: v=0 o=njh 3310243893 3310243893 IN IN4 hwickabab.ecs.soton.ac.uk s=SURGE Live! i=Southampton University's Radio from Glen Eyre t=0 0 a=type:broadcast m=audio 8000 http mpeg c=IN IP4 152.78.104.83 a=http-path:/surge-live-high-mp3 This is modeled on a SDP description I saw generated by VLC/miniSAPserver - I don't think it is based on any Internet Draft. By combining the 'audio' and the 'mpeg' in the m= line, you get the MIME type of the HTTP stream... nick. On 23 Nov 2004, at 21:32, Ross Finlayson wrote: > >> Well there's descriptive language in the RTSP document itself. > > I don't think so. The RTSP specification notes that a SDP description > for a stream *could* be received using a HTTP "GET", instead of using > a RTSP "DESCRIBE". But that's not what Nicholas Humfrey was asking > about. I believe he was asking how to describe a HTTP (as opposed to > RTP) media stream within SDP. I.e., his question really didn't have > anything to do with RTSP. > > Ross. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Thu Nov 25 10:25: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 KAA21269 for ; Thu, 25 Nov 2004 10:25:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLZK-0006QQ-09 for mmusic-web-archive@ietf.org; Thu, 25 Nov 2004 10:30:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLTh-0004wQ-2V; Thu, 25 Nov 2004 10:24:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLJw-0001OG-M0 for mmusic@megatron.ietf.org; Thu, 25 Nov 2004 10:14:08 -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 KAA20108 for ; Thu, 25 Nov 2004 10:14:06 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLNq-0006A7-W9 for mmusic@ietf.org; Thu, 25 Nov 2004 10:18:22 -0500 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 iAPFDth5004259 for ; Thu, 25 Nov 2004 16:13:55 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 16:13:54 +0100 Received: from [147.214.97.152] (RESEARCH-1FD0E1 [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHLS5GQJ; Thu, 25 Nov 2004 16:13:54 +0100 Message-ID: <41A5F6B1.5030403@ericsson.com> Date: Thu, 25 Nov 2004 16:13:53 +0100 X-Sybari-Trust: 8c4950f1 a5e9b67f be1bd75b 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: Mark Crosland Subject: Re: [MMUSIC] RTSP session identifiers References: <3D8E54E3CAA3864295233C618F53F2AD82EFF5@exchfour.olympus.f5net.com> In-Reply-To: <3D8E54E3CAA3864295233C618F53F2AD82EFF5@exchfour.olympus.f5net.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-OriginalArrivalTime: 25 Nov 2004 15:13:54.0700 (UTC) FILETIME=[60E0F4C0:01C4D301] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by penguin.ericsson.se id iAPFDth5004259 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: quoted-printable Hi Mark, Sorry for not responding before, see below for my comments. Mark Crosland wrote: > I have a question regarding RTSP session IDs that perhaps someone would= =20 > answer. >=20 > RFC 2326 indicates that an RTSP session identifier is not tied to a=20 > single TCP connection or some well-defined set > of UDP packets (1.1, 1.7, 12.37, 16 session hijacking). >=20 > I am curious as to what a use-case or two might be where a session ID=20 > spans multiple TCP connections to the server? I=92m guessing here, but=20 > would they revolve around conferencing? >=20 The reasons that RTSP has session ID is not tied to a specific transport=20 is many: - Support of UDP / non-connection oriented transport - The possibility to have one transport connection that controls=20 multiple sessions. - Fault tolerance, against the loss of a transport connection when in a=20 session. There are also has been considered to use the session ID as a=20 possibility to pass the control between multiple users in a conference=20 that share the streaming servers output. > =20 >=20 > For the generic video/audio user on the internet I assume that when the= y=20 > exit out of something like real player or windows media player, that th= e=20 > server stops streaming data to them, and the chances of them=20 > reconnecting to the server and resuming where they left off are slim.=20 > But perhaps that is only because the clients don=92t support that mode = of=20 > operation, i.e., saving RTSP session IDs, reconnecting to a server and=20 > resuming the data stream. >=20 A session and its ID is not a long lived entity normally, the default=20 session timeout is 60 seconds. Thus it can't normally be used to save=20 the state and later return to the session. What has been discussed has=20 been application layer mobility, where after a change of IP address the=20 client reconnects to the session and do a new SETUP to move to streams=20 to the new address. Another case has been to move the session between=20 devices, for example between the living room and the bedroom displays. > =20 >=20 > Do most media clients and servers out there support session management=20 > across multiple control channels? >=20 There are some servers that support it, some other that do not. In the=20 discussion on the topic the conclusion is to mandate servers to shall be=20 required to support non-permanent transport connection. The main=20 motivation being fault tolerance. 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 Nov 25 10:45:45 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 KAA22810 for ; Thu, 25 Nov 2004 10:45:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLsQ-0006nt-QR for mmusic-web-archive@ietf.org; Thu, 25 Nov 2004 10:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLgE-0000ZQ-Vn; Thu, 25 Nov 2004 10:37:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLfP-0000Nx-Lw for mmusic@megatron.ietf.org; Thu, 25 Nov 2004 10:36:19 -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 KAA22091 for ; Thu, 25 Nov 2004 10:36:17 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLjI-0006dJ-3k for mmusic@ietf.org; Thu, 25 Nov 2004 10:40:34 -0500 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 iAPFa4h5008389 for ; Thu, 25 Nov 2004 16:36:04 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 16:36:04 +0100 Received: from [147.214.97.152] (RESEARCH-1FD0E1 [147.214.97.152]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVZBKGN; Thu, 25 Nov 2004 16:36:03 +0100 Message-ID: <41A5FBE2.6030801@ericsson.com> Date: Thu, 25 Nov 2004 16:36:02 +0100 X-Sybari-Trust: 95848cf9 a5e9b67f be1bd75b 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: Ross Finlayson Subject: Re: [MMUSIC] A comment re. draft-ietf-mmusic-rfc2326bis-06.txt References: <6.2.0.14.1.20041123133318.031a0370@localhost> In-Reply-To: <6.2.0.14.1.20041123133318.031a0370@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2004 15:36:04.0282 (UTC) FILETIME=[795F11A0:01C4D304] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Hi Ross, See below: Ross Finlayson wrote: > In section 16.4 ("Live Media Presentation Using Multicast") there's the > following "Editor's Note"): > > Is this example really valid? In what situations does it make sense to do a > setup to a multicast distribution channel, and also issue PLAY requests? > > Please remove this "Editor's Note". As I noted in a message to this > mailing list back in August: > Yes, I don't see a big problem with removing the editors note. However the question was also on a more technical level rather than on the principle level. So have you looked at the actual example and think it is correct? I am also sorry that I didn't manage to edit the draft to the shape I have desired before the meeting. There are a number of open issues not edited in, and this editorial note, is clearly one things that needs to be concluded. 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 Nov 25 10:54: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 KAA23772 for ; Thu, 25 Nov 2004 10:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXM15-00075N-4Y for mmusic-web-archive@ietf.org; Thu, 25 Nov 2004 10:58:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLp7-00027k-8e; Thu, 25 Nov 2004 10:46:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXLlI-0001Pc-Hy for mmusic@megatron.ietf.org; Thu, 25 Nov 2004 10:42:25 -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 KAA22610 for ; Thu, 25 Nov 2004 10:42:22 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXLpM-0006kT-Dn for mmusic@ietf.org; Thu, 25 Nov 2004 10:46:39 -0500 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 iAPFgKvD029366 for ; Thu, 25 Nov 2004 16:42:20 +0100 (MET) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 16:42:18 +0100 Received: from [147.214.97.152] (RESEARCH-1FD0E1 [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WHLS5MPB; Thu, 25 Nov 2004 16:42:18 +0100 Message-ID: <41A5FD59.7060809@ericsson.com> Date: Thu, 25 Nov 2004 16:42:17 +0100 X-Sybari-Trust: d4720419 a5e9b67f be1bd75b 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: 25 Nov 2004 15:42:18.0786 (UTC) FILETIME=[5897D820:01C4D305] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Text proposal for new error code 463 (Destination Prohibited) 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, Sean has provided text for the 463 error code. I think it looks fine, and would like check if there is any further feedback before including it in the specification. Cheers Magnus ---- Proposal begins ----- For Table 4: 463 Destination Prohibited SETUP Add new section: 13.4.15 463 Destination Prohibited The data transmission channel was not established because the server prohibited access to the client address. This error is most likely the result of a client attempt to redirect media traffic to another destination with a either a Destination or a dest_addr parameter in the Transport field. Add to section 14.45 Transport, "destination" subsection: If the server does not allow the destination field to be set, it SHALL return 463 (Destination Prohibited). Add to section 14.45 Transport, "dest_addr" subsection: If the server does not allow the dest_addr field to be set, it SHALL return 463 (Destination Prohibited). ------- end of proposal ----------- -- 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 Nov 26 10:37:12 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 KAA19196 for ; Fri, 26 Nov 2004 10:37:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiE9-0003w6-53 for mmusic-web-archive@ietf.org; Fri, 26 Nov 2004 10:41:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi43-0007Hm-0S; Fri, 26 Nov 2004 10:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhnO-0005C2-5h for mmusic@megatron.ietf.org; Fri, 26 Nov 2004 10:14:02 -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 FAA26190 for ; Fri, 26 Nov 2004 05:42:18 -0500 (EST) 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 1CXdcj-0005Ky-5b for mmusic@ietf.org; Fri, 26 Nov 2004 05:46:45 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAQAgEv05653; Fri, 26 Nov 2004 12:42:16 +0200 (EET) X-Scanned: Fri, 26 Nov 2004 12:44:32 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAQAiWL4011316; Fri, 26 Nov 2004 12:44:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006hpFTw; Fri, 26 Nov 2004 12:44:30 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAQAfFa13462; Fri, 26 Nov 2004 12:41:16 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Nov 2004 12:41:16 +0200 Received: from trebe051.NOE.Nokia.com ([172.22.124.60]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 26 Nov 2004 12:41:15 +0200 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] SDP description for HTTP/RTSP streams Date: Fri, 26 Nov 2004 12:41:15 +0200 Message-ID: Thread-Topic: [MMUSIC] SDP description for HTTP/RTSP streams Thread-Index: AcTRjGesdXCWuqqgQxizbFbEF+2UvAAV+NbA To: , X-OriginalArrivalTime: 26 Nov 2004 10:41:15.0322 (UTC) FILETIME=[7457B9A0:01C4D3A4] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable An HTTP/TCP protocol ID would be useful for this (although this is = clearly an evil thing that you are doing, suggesting this in AVT might = get you burnt at the stake :) (I haven't yet worked out the process for registering the much more = angelical FLUTE/UDP protocol ID but I am told it is straightforward - so = I live in blissful and unhelpful ignorance for now) Otherwise I guess SDP already has all you need. It's worth taking a look = at the mandatory fields to see which are helpful (e.g. do you want to = time bound or is the tear-down of the TCP enough), as well as the = multitude of options (e.g. do you expect to specify the bandwidth in = detail, any capabilities requirements need making explicit?). If your use case if "first try RTP/UDP" and then "something/TCP" you = might be using a similar "alternative media" semantic to ANAT. ANAT = provides a way to swap to an alternative IP addressing media (e.g. one = media using v4 and one using v6). Might be worth a look (and sorry if it = turns out to be a wild goose chase). Cheers, Rod. > -----Original Message----- > From: mmusic-bounces@ietf.org=20 > [mailto:mmusic-bounces@ietf.org]On Behalf > Of ext Nicholas Humfrey > Sent: Tuesday, November 23, 2004 8:28 PM > To: mmusic@ietf.org > Subject: [MMUSIC] SDP description for HTTP/RTSP streams >=20 >=20 >=20 > Hi, >=20 >=20 > I have been trawling the web to see if there is an official way to=20 > describe a RTSP/HTTP (URI) stream using SDP. >=20 > I have seen some SDP descriptions that put 'http' into the transport=20 > in m=3D, the server in c=3D, and the path as an attribute. >=20 >=20 > Has there been any Internet draft to standardize this ? >=20 >=20 > I have mixed feelings about it - half of me thinks it is 'wrong' and=20 > there are better ways of describing these types of (evil ;-)=20 > shoutcast/icecast streams as URIs (M3U, PLS). >=20 > But the other half of me thinks it would be nice to be able to=20 > describe all types of media streams using SDP and announce them over=20 > SAP. And store them in a common format in directories of streams. >=20 >=20 >=20 > nick. >=20 >=20 >=20 > PS. Advertisement for my two perl modules: >=20 > http://search.cpan.org/~njh/Net-SAP/ > http://search.cpan.org/~njh/Net-SDP/ >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Fri Nov 26 10:47: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 KAA20864 for ; Fri, 26 Nov 2004 10:47:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXiOE-0004Mc-Or for mmusic-web-archive@ietf.org; Fri, 26 Nov 2004 10:52:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXi4r-0008In-2I; Fri, 26 Nov 2004 10:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhox-0007i0-Vy for mmusic@megatron.ietf.org; Fri, 26 Nov 2004 10:15:40 -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 CAA14585 for ; Fri, 26 Nov 2004 02:21:57 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXaUk-00017y-9F for mmusic@ietf.org; Fri, 26 Nov 2004 02:26:20 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAQ7LmR2019468 for ; Fri, 26 Nov 2004 08:21:48 +0100 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, 26 Nov 2004 08:21:48 +0100 Received: from ericsson.com (EFO9N000L5C7100 [153.88.40.79]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WRVZGB72; Fri, 26 Nov 2004 08:21:46 +0100 Message-ID: <41A6D98A.6020603@ericsson.com> Date: Fri, 26 Nov 2004 09:21:46 +0200 X-Sybari-Trust: 45091551 a5e9b67f 4c710f86 00000139 From: Gonzalo Camarillo 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: "James M. Polk" References: <4.3.2.7.2.20041108082500.0273c7b8@localhost> In-Reply-To: <4.3.2.7.2.20041108082500.0273c7b8@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2004 07:21:48.0034 (UTC) FILETIME=[97487E20:01C4D388] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: [MMUSIC] Re: Connection-Establishment Preconditions question 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 James, > Shouldn't the example in draft-ietf-mmusic-connection-precon-00.txt be > taken through the message flow point that the attribute lines are: > > a=curr e2e sendrecv > a=des e2e mandatory sendrecv > > for clarity? The example is complete. The thing is that, since the callee is the last one setting up his radio bearer, it does not need to generate any further offer informing the caller. It just knows that the caller is ready (because of the offer received previously) and that it itself (the callee) is ready as well. So, it simply sends a TCP SYN and, when the connection is ready, it starts alerting the user. Thanks, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Mon Nov 29 16:31: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 QAA09521 for ; Mon, 29 Nov 2004 16:31:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtCd-0005yI-2X for mmusic-web-archive@ietf.org; Mon, 29 Nov 2004 16:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYs1f-0000f4-QF; Mon, 29 Nov 2004 15:21:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYrwy-0006LM-RL; Mon, 29 Nov 2004 15:16:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27092; Mon, 29 Nov 2004 15:16:43 -0500 (EST) Message-Id: <200411292016.PAA27092@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 29 Nov 2004 15:16:42 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-22.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-22.txt Pages : 47 Date : 2004-11-29 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-22.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-22.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-22.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-11-29152225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-22.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-22.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-29152225.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 Tue Nov 30 04:45:40 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 EAA26779 for ; Tue, 30 Nov 2004 04:45:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ4et-0006at-Fu for mmusic-web-archive@ietf.org; Tue, 30 Nov 2004 04:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ48H-0003Pd-28; Tue, 30 Nov 2004 04:17:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ3y5-0002Dv-RW for mmusic@megatron.ietf.org; Tue, 30 Nov 2004 04:06:42 -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 EAA23062 for ; Tue, 30 Nov 2004 04:06:39 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ43A-0005pG-Sg for mmusic@ietf.org; Tue, 30 Nov 2004 04:11:57 -0500 Received: from [217.114.49.39] (port=50196 helo=[10.30.120.25]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CZ3xX-0005M6-CO; Tue, 30 Nov 2004 09:06:07 +0000 In-Reply-To: <77E2BCAC-3DC8-11D9-97B4-000D9357E16C@ecs.soton.ac.uk> References: <2D0CA64CDC33E14DA7AB043B8CC4D2BB027451EC@svr-exc.domain.com> <6.2.0.14.1.20041123132739.03227c30@localhost> <77E2BCAC-3DC8-11D9-97B4-000D9357E16C@ecs.soton.ac.uk> 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] SDP description for HTTP streams Date: Mon, 29 Nov 2004 16:29:11 +0000 To: Nicholas J Humfrey X-Mailer: Apple Mail (2.619) X-Spam-Score: 2.5 (++) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: 2.5 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Nick, On 24 Nov 2004, at 03:25, Nicholas J Humfrey wrote: > Yes Ross is right. Sorry I didn't make it clear what I meant before. > Here is an example of a URI to a Icecast stream: > > http://152.78.104.83:8000/surge-live-high-mp3 > > And here is a proposed SDP description of that URI: > > v=0 > o=njh 3310243893 3310243893 IN IN4 hwickabab.ecs.soton.ac.uk > s=SURGE Live! > i=Southampton University's Radio from Glen Eyre > t=0 0 > a=type:broadcast > m=audio 8000 http mpeg > c=IN IP4 152.78.104.83 > a=http-path:/surge-live-high-mp3 > > This is modeled on a SDP description I saw generated by > VLC/miniSAPserver - I don't think it is based on any Internet Draft. Looks reasonable, although I don't think it's documented anywhere. If there's a future option of running HTTP over something other than TCP, then it might make sense to use "m=audio 8000 TCP/HTTP mpeg" to align with the comedia spec (draft-ietf-mmusic-sdp-comedia-09.txt). Would you be willing to write up a draft documenting this? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 30 05:53: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 FAA04416 for ; Tue, 30 Nov 2004 05:53:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ5j2-0008Ha-UJ for mmusic-web-archive@ietf.org; Tue, 30 Nov 2004 05:59:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5UW-0002re-Uv; Tue, 30 Nov 2004 05:44:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ5R1-0001fZ-Ea for mmusic@megatron.ietf.org; Tue, 30 Nov 2004 05:40:39 -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 FAA03075 for ; Tue, 30 Nov 2004 05:40:36 -0500 (EST) Received: from mr1.dcs.gla.ac.uk ([130.209.249.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ5W6-0007sW-C2 for mmusic@ietf.org; Tue, 30 Nov 2004 05:45:55 -0500 Received: from [217.114.49.39] (port=50621 helo=[10.30.120.25]) by mr1.dcs.gla.ac.uk with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.42) id 1CZ5QU-0004bs-MI for mmusic@ietf.org; Tue, 30 Nov 2004 10:40:06 +0000 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200411292016.PAA27092@ietf.org> References: <200411292016.PAA27092@ietf.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AF42163-42BC-11D9-B611-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit From: Colin Perkins Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-22.txt Date: Tue, 30 Nov 2004 10:39:52 +0000 To: IETF MMUSIC Working Group X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit On 29 Nov 2004, at 20:16, 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-22.txt > Pages : 47 > Date : 2004-11-29 > > 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-22.txt Changes in this version are: - Fix typo in section 5.14 - Allow "message" as a media type in "m=" lines - Update references - Note that internationalized domain names MUST use the ACE format defined in RFC 3490, rather than being directly represented in UTF-8. - Note that the "control" and "data" media types are defined in RFC 3840 but not in this version of SDP or as top-level MIME types. - Add summary of changes from RFC 2327 I believe this is now ready for working group last call. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-bounces@ietf.org Tue Nov 30 16:41:27 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 QAA14955 for ; Tue, 30 Nov 2004 16:41:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZFpj-0002cb-He for mmusic-web-archive@ietf.org; Tue, 30 Nov 2004 16:46:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZEeh-0002Jr-33; Tue, 30 Nov 2004 15:31:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZELA-0007fP-Os; Tue, 30 Nov 2004 15:11:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28898; Tue, 30 Nov 2004 15:11:10 -0500 (EST) Message-Id: <200411302011.PAA28898@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 30 Nov 2004 15:11:10 -0500 Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-comedia-10.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-Oriented Media Transport in the Session Description Protocol (SDP) Author(s) : D. Yon Filename : draft-ietf-mmusic-sdp-comedia-10.txt Pages : 15 Date : 2004-11-30 This document describes how to express media transport over TCP using the Session Description Protocol (SDP). It defines the SDP 'TCP' protocol identifier, the SDP 'setup' attribute, which describes the connection setup procedure, and the SDP 'connection' attribute, which handles connection reestablishment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-10.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-comedia-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-10.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-11-30111331.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-comedia-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-30111331.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 Tue Nov 30 18:54: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 SAA01656 for ; Tue, 30 Nov 2004 18:54:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZHuA-0007RT-7n for mmusic-web-archive@ietf.org; Tue, 30 Nov 2004 18:59:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZHm1-0007pl-Fx; Tue, 30 Nov 2004 18:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZHh2-0006fy-Aq for mmusic@megatron.ietf.org; Tue, 30 Nov 2004 18:46:01 -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 SAA01349 for ; Tue, 30 Nov 2004 18:45:57 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZHmE-0007JS-Nk for mmusic@ietf.org; Tue, 30 Nov 2004 18:51:23 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2004 15:45:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id iAUNjPA5022289; Tue, 30 Nov 2004 15:45:25 -0800 (PST) Received: from [192.168.0.11] (sjc-vpn4-548.cisco.com [10.21.82.36]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id iAUNiv4p005401; Tue, 30 Nov 2004 15:44:57 -0800 In-Reply-To: <7D052489-3E77-11D9-A16E-000A95DC10F2@cisco.com> References: <7D052489-3E77-11D9-A16E-000A95DC10F2@cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Tue, 30 Nov 2004 15:45:21 -0800 To: Alan Clark X-Mailer: Apple Mail (2.619) IIM-SIG: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1101858297.546244"; x:"432200"; a:"rsa-sha1"; b:"nofws:15904"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"Z6wYR0MEEHm3uua9iwFAmgZrDE8Uooj76BsPCYw9eaDEyD8meBYtFsLmCZ0o4" "eQx4eryblgbNeMPC4pWuTBj5F64tL4kzHi7makIZ+FA8bH0uObUcxRcptbwIz" "WfUF37ed6MplkkwUT8MqKrQNzi23Jjvtz71TSIiv9esVsUwwM="; c:"From: Mark Baugher "; c:"Subject: Re: [AVT] RFC 3711 and RTCP"; c:"Date: Tue, 30 Nov 2004 15:45:21 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.2 (/) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 Content-Transfer-Encoding: 7bit Cc: mmusic@ietf.org Subject: [MMUSIC] Re: [AVT] RFC 3711 and RTCP 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.2 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Content-Transfer-Encoding: 7bit Alan I am copying MMUSIC (and not cross-posting to AVT) to further discuss a possible change to SDP security descriptions, which has completed WG last call. The change is needed for RFC 3611, and we also discovered that http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions -07.txt does not address the SRTCP E bit properly. I offered the following text in a posting to AVT: "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP packets MUST have the E bit set to zero and MUST NOT be encrypted. Otherwise, all SRTP packets MUST have the E bit set to one and MUST be encrypted by default. Individual applications MAY override these default behaviors in their specifications. In a session where SRTCP packets are encrypted, therefore, applications that use RFC 3611 MAY set the E bit to 0 for XR packets as recommended by RFC 3611." One of my co-authors pointed out that the last sentence is more than an editorial change. We also don't like the fact that an offerer or answerer cannot explicitly signal when it wants the XR packet to be encrypted or unencrypted. In other words, if ENCRYPTED_SRTCP is the default setting and RFC 3611 is also signaled, it is ambiguous as to whether the SRTCP sender will encrypt the XR packet or not. It's solely up to the sender. If the offerer or answerer want the XR packet to always be encrypted, there is no way to signal that. Ditto for the unencrypted case. I think we need to put the first three sentences of the above-quoted paragraph into SDP security descriptions as an editorial change. I'm proposing this to the working group. I also propose not to include the last sentence. Instead, we could add a new signaling parameter, UNENCRYPTED_XR, which implies that all SRTCP messages are to be encrypted except for the XR packets, which will have their E bit clear, of course. This new parameter could be placed in an RFC 3611bis or in a revision of draft-ietf-mmusic-sdescriptions-07.txt, which will then need to undergo another WG last call. What do you (all) think about this? Mark On Nov 24, 2004, at 4:18 PM, Mark Baugher wrote: > Alan > As Dave Oran has pointed out, the definition that you want is not > supported in the signaling, at present. The current definition of > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions > -07.txt treats SRTCP encryption as either on or off and does not > address the problem of setting the E bit in SRTCP packets. This is a > bug that we need to fix. > > MMUSIC has finished last call on > draft-ietf-mmusic-sdescriptions-07.txt, and the transport ADs have > reviewed it. We'll be making some changes at Jon Peterson's request > and post another version in about a week. This is an opportunity to > address the E bit, but the MMUSIC chairs or transport ADs may want > another WG last call. Off the top of my head, I would offer something > like the following. > > "As the default behavior when UNENCRYPTED_SRTCP is signaled, all SRTCP > packets MUST have the E bit set to zero and MUST NOT be encrypted. > Otherwise, all SRTP packets MUST have the E bit set to one and MUST be > encrypted by default. Individual applications MAY override these > default behaviors in their specifications. In a session where SRTCP > packets are encrypted, therefore, applications that use RFC 3611 MAY > set the E bit to 0 for XR packets as recommended by RFC 3611." > > Mark > > On Nov 24, 2004, at 2:33 PM, Alan Clark wrote: > >> >> >> Mark >> >> We tried to flag this in RFC3611 with the following text in the >> "security >> considerations" section >> >> Any encryption or filtering of XR report blocks entails a loss of >> monitoring information to third parties. For example, a network >> that >> establishes a tunnel to encrypt VoIP Report Blocks denies that >> information to the service providers traversed by the tunnel. The >> service providers cannot then monitor or respond to the quality of >> the VoIP calls that they carry, potentially creating problems for >> the >> network's users. As a default, XR packets should not be encrypted >> or >> filtered. >> >> Could we potentially interpret this as being the definition of what to >> selectively encrypt in the case of the RFC3611 specification? >> >> Regards >> >> Alan >> >> >> -----Original Message----- >> From: Mark Baugher [mailto:mbaugher@cisco.com] >> Sent: Wednesday, November 24, 2004 2:42 PM >> To: Alan Clark >> Cc: Oren Peleg; Cullen Jennings; avt@ietf.org; David R Oran; Michael >> A. >> Ramalho >> Subject: Re: [AVT] RFC 3711 and RTCP >> >> >> So, when the sender and receiver agree to encrypt SRTCP, this would >> mean >> only that some SRTCP messages would be encrypted and the sender would >> decide which ones to encrypt? My personal opinion is that this is not >> secure because it is unpredictable to the receiver, which may have a >> policy that all messages related to its session be encrypted. >> >> I can think of a few potential approaches to this problem. >> >> 1. Let individual SRTCP messages or a bundle of SRTCP messages >> be signaled to be unencrypted when SRTCP encryption is used. >> >> 2. Make a blanket policy that the sender determine what >> to selectively encrypt, as you suggest. >> >> 3. Define the policy of what to selectively encrypt in >> the particular specification. In other words, a document could >> re-define the signaling of SRTCP encryption according to its >> needs. The specification of foo, therefore, could define a new >> parameter such as foo_ENCRYPTED_SRTCP to be used in place of >> ENCRYPTED_SRTCP. The foo document would define what gets >> encrypted and what does not get encrypted as per its needs. >> >> I commented on #2 already. I don't like #1 because of its signaling >> complexity. I like #3 because it limits the complexity to the >> specific needs of an application. #1 would be more efficient than >> #3 if lots of applications had their own specific needs for >> selective encryption of SRTCP message. But I don't think this is >> the case. >> >> Mark >> >> On Nov 24, 2004, at 10:58 AM, Alan Clark wrote: >> >>> >>> If the use of encryption in SRTCP is signalled by an explicit (E) bit >>> in the >>> SRTCP header then perhaps the sender could autonomously decide >>> whether >>> it >>> wants to encrypt? Presumably since the sender is in the best >>> position >>> to >>> decide if the data is sensitive then this would be ok - and the >>> receiver is >>> able to just look at the E bit and hence recognize that decryption is >>> needed. >>> >>> Alan >>> >>> -----Original Message----- >>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org]On Behalf Of >>> Mark Baugher >>> Sent: Wednesday, November 24, 2004 1:33 PM >>> To: David R Oran >>> Cc: Cullen Jennings; Oren Peleg; Michael A. Ramalho; Alan Clark; >>> avt@ietf.org >>> Subject: Re: [AVT] RFC 3711 and RTCP >>> >>> >>> >>> On Nov 24, 2004, at 10:05 AM, David R Oran wrote: >>> >>>> >>>> On Nov 24, 2004, at 12:23 PM, Alan Clark wrote: >>>> >>>>> >>>>> Michael >>>>> >>>>> I don't see why this would be a problem unless you included SDES >>>>> and >>>>> (SR or >>>>> RR or XR) in the same RTCP packet. SRTP (at least the protocol) is >>>>> apparently able to decided on a packet by packet basis whether to >>>>> encrypt >>>>> RTCP - hopefully SRTP implementations also permit this. >>>>> >>>> Sure, they can do this. But remember offer-answer. How does a >>>> receiver >>>> communicate such a granular policy to the transmitter? Right now if >>>> can say whether to auth or auth+encrypt RTP, and auth or >>>> auth+encrypt >>>> RTCP. There's no way to say auth+encrypt SDES but only auth SR/XR >>>> etc. >>> >>> Seems to me that this is a problem with SDP security descriptions. >>> That problem might be there because we forgot about the E bit. This >>> seems very messy for the reason you mention above - granularity. I >>> don't think that we want to negotiate the encryption policy for each >>> type SDP message, which is a problem with something like the E bit. >>> >>> Mark >>>> >>>> >>>>> Logically I'd send SDES on its own at the start of a call to >>>>> provide >>>>> some >>>>> user info, but would not send SR/RR/XR until at least 8-10 seconds >>>>> into the >>>>> call as I need some time to gather statistics to report. >>>> That's not exactly what the RTP specs say. RTCP timers don't have >>>> this >>>> kind of policy today. In fact, there are porposals on the table to >>>> use >>>> RTCP for early feedback to assess reception quality on some initial >>>> packets - e.g. the RTP-noop proposal. In any event that has no >>>> bearing >>>> on the present discussion. >>>> >>>>> After the >>>>> start-of-call exchange there would appear to be minimal need to >>>>> include >>>>> SDES. I'm sure we could construct some scenarios in which you "may" >>>>> need to >>>>> include SDES with SR/RR/XR however the vast majority of cases would >>>>> either >>>>> need only a single initial exchange or may not need SDES at all. >>>>> >>>> Any time you change SSRC you potentially need to send SDES. >>>> That said, I still don't see what bearing this has on the discussion >>>> about whether we need the complexity of encrypting some RTCP packets >>>> and not others for a single session. >>>> >>>> It's a tradeoff between extra complexity+less privacy versus >>>> allowing >>>> snoopers to gather RTCP stats. >>>> >>>> Dave. >>>> >>>>> Regards >>>>> >>>>> Alan >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Michael A. Ramalho [mailto:mramalho@cisco.com] >>>>> Sent: Wednesday, November 24, 2004 9:39 AM >>>>> To: Alan Clark >>>>> Cc: Oren Peleg; avt@ietf.org >>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>> >>>>> >>>>> At 07:54 AM 11/24/2004 -0500, Alan Clark wrote: >>>>>> Hi Oren >>>>>> >>>>>> Yes - encryption is intended to provide privacy however this >>>>>> relates >>>>>> primarily to the voice payloads and to information within RTCP >>>>>> that >>>>>> may be >>>>>> associated with individual users (e.g. SDES). >>>>>> >>>>>> SR, RR and XR contain only peformance statistics and there is no >>>>>> privacy >>>>>> consideration that I can think of related to this type of data. >>>>>> >>>>>> The message is - encrypt RTP, optionally encrypt RTCP SDES but >>>>>> don't >>>>> encrypt >>>>>> RTCP SR/RR/XR >>>>> >>>>> Hi Alan, >>>>> >>>>> I am wondering about implementations utilizing your advise >>>>> "optionally >>>>> encrypt >>>>> RTCP SDES but don't encrypt RTCP SR/RR/XR". >>>>> >>>>> Is there an easy way to tell SRTP to encrypt RTCP SDES, but not >>>>> RTCP >>>>> SR/RR/XR? It seems that all the RTCP blocks would otherwise be >>>>> highly >>>>> related to each other. For example (quote out of RFC 3611): >>>>> >>>>> "XR packets supplement the existing RTCP packets, and may be >>>>> stacked >>>>> with >>>>> other RTCP packets to form compound RTCP packets [9, Section 6]." >>>>> >>>>> Thus, RFC3611 explicitly admits the possibility of (but does not >>>>> mandate) >>>>> the piggybacking all the RTCP-XR block types. >>>>> >>>>> RTCP implementations would have to know the SRTP encryption rules >>>>> to >>>>> make sure they don't perform piggybacking with SDES ... but could >>>>> allow >>>>> (the more bandwidth efficient) piggybacking on the other RTCP-XR >>>>> blocks. >>>>> >>>>> This RTCP/SRTP interaction/dependency seems to add a burden to both >>>>> RTCP and SRTP implementations ... let alone the expressiveness >>>>> required >>>>> to signal your advise in existing SDP/SRTP mechanisms. >>>>> >>>>> Are you aware of any implementations that have actually followed >>>>> your >>>>> advise above? I rather go into this one with our eyes open ... >>>>> developers >>>>> highly dislike this cross-functional entity dependency (RTCP & SRTP >>>>> along >>>>> with expressing it in SDP/SRTP mechanisms). >>>>> >>>>> Regards, >>>>> >>>>> Michael Ramalho >>>>> >>>>> >>>>> >>>>>> Regards >>>>>> >>>>>> Alan >>>>>> >>>>>> -----Original Message----- >>>>>> From: Oren Peleg [mailto:OrenP@audiocodes.com] >>>>>> Sent: Wednesday, November 24, 2004 7:50 AM >>>>>> To: Alan Clark; avt@ietf.org >>>>>> Subject: RE: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>> >>>>>> Isnt encryption is to prevent monitoring from the first place? >>>>>> >>>>>> -----Original Message----- >>>>>> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf >>>>>> Of >>>>>> Alan Clark >>>>>> Sent: Tuesday, November 23, 2004 5:42 PM >>>>>> To: avt@ietf.org >>>>>> Subject: [AVT] RFC 3711 and RTCP >>>>>> >>>>>> >>>>>>> From the flurry of discussion on RFC3711 it looks as if there is >>>>>> considerable interest in SRTP implementation. I'd like to add a >>>>>> request >>>>>> to >>>>>> SRTP implementors with regard to manageability. >>>>>> >>>>>> RTCP SR, RR and more particularly XR (e.g. VoIP Metrics report >>>>>> block) >>>>>> contain useful information for network monitoring, and are often >>>>>> used by >>>>>> probes and analyzers to support problem diagnosis. RFC3711 allows >>>>>> the >>>>>> selective encryption of RTCP payloads and hence I would strongly >>>>>> recomment >>>>>> that RFC3711 implementors DO NOT encrypt RTCP SR, RR and XR >>>>>> payloads >>>>>> as >>>>>> this >>>>>> adversely impacts manageability. >>>>>> >>>>>> Regards >>>>>> >>>>>> Alan Clark >>>>>> Telchemy >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>>> >>>>>> ****************************************************************** >>>>>> ** >>>>>> * >>>>>> ****** >>>>> * >>>>>> ******************************** >>>>>> This email and any files transmitted with it are confidential >>>>>> material. >>>>>> They are intended solely for the use of the designated individual >>>>>> or >>>>>> entity >>>>>> to whom they are addressed. >>>>>> If the reader of this message is not the intended recipient, >>>>>> you are hereby notified that any dissemination,use, >>>>>> distribution or copying of this communication is strictly >>>>>> prohibited >>>>>> and >>>>> may >>>>>> be unlawful. >>>>>> >>>>>> If you have received this email in error please notify >>>>>> postmaster@audiocodes.com and permanently delete the e-mail and >>>>>> files. >>>>>> >>>>>> >>>>>> ****************************************************************** >>>>>> ** >>>>>> * >>>>>> ****** >>>>> * >>>>>> ******************************* >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Audio/Video Transport Working Group >>>>>> avt@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>>> >>>>> _______________________________________________ >>>>> Audio/Video Transport Working Group >>>>> avt@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/avt >>>>> >>>> David R. Oran >>>> Cisco Fellow >>>> Cisco Systems >>>> 7 Ladyslipper Lane >>>> Acton, MA 01720 USA >>>> Tel: +1 978 264 2048 >>>> Email: oran@cisco.com >>>> >>>> >>>> _______________________________________________ >>>> Audio/Video Transport Working Group >>>> avt@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/avt >>>> >>> >>> >>> _______________________________________________ >>> Audio/Video Transport Working Group >>> avt@ietf.org >>> https://www1.ietf.org/mailman/listinfo/avt >>> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic