From mailnull@www1.ietf.org Tue Apr 1 07:11:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06552 for ; Tue, 1 Apr 2003 07:11:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31CZ9a23730 for mmusic-archive@odin.ietf.org; Tue, 1 Apr 2003 07:35:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CZ9K23727 for ; Tue, 1 Apr 2003 07:35:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06542 for ; Tue, 1 Apr 2003 07:10:53 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CYQK23666; Tue, 1 Apr 2003 07:34:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31CXjK23399 for ; Tue, 1 Apr 2003 07:33:45 -0500 Received: from gw-nl6.philips.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06443 for ; Tue, 1 Apr 2003 07:09:29 -0500 (EST) From: philippe.gentric@philips.com Received: from smtpscan-nl1.philips.com (smtpscan-nl1.philips.com [130.139.36.21]) by gw-nl6.philips.com (Postfix) with ESMTP id A103FA7012; Tue, 1 Apr 2003 14:11:53 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA19929; Tue, 1 Apr 2003 14:11:52 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id OAA12910; Tue, 1 Apr 2003 14:11:50 +0200 (MET DST) Subject: Re: [MMUSIC] RTSP server behind NAT To: Jonathan Rosenberg Cc: Magnus Westerlund , mmusic@ietf.org, Thomas Zeng X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Tue, 1 Apr 2003 14:04:12 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 01/04/2003 14:12:52 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , >NATs on both sides does not always require a relay on the public >Internet. It only does if both NATs are symmetric. If at least one is >full cone, port restricted, etc., then the relay can be avoided. ICE >will make this determination for you, and only use TURN if connectivity >cannot be established directly. I understand: one always need at least one public server, but in some cases that server does not have to "relay" i.e. process the data, instead the system is configured so that data flows directly from peer to peer. > ...consider the model where SIP is used to establish > the session, and then RTSP is introduced for the control aspects. ......... >Thoughts? Implementing SIP looks like a *lot* of work !-) regards, Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 1 12:08:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00220 for ; Tue, 1 Apr 2003 12:08:27 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31HWHl09321 for mmusic-archive@odin.ietf.org; Tue, 1 Apr 2003 12:32:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HWHK09318 for ; Tue, 1 Apr 2003 12:32:17 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00124 for ; Tue, 1 Apr 2003 12:07:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HWBK09302; Tue, 1 Apr 2003 12:32:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HVfK09220 for ; Tue, 1 Apr 2003 12:31:41 -0500 Received: from [208.236.204.65] (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00055; Tue, 1 Apr 2003 12:07:19 -0500 (EST) Received: from NAMASMTP02 by [208.236.204.65] via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 12:05:01 UT Subject: RE: [MMUSIC] RTSP teleconference, have or not? To: Thomas Zeng Cc: Magnus Westerlund , IETF MMUSIC WG , mmusic-admin@ietf.org, "'Tom Marshall'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Tue, 1 Apr 2003 12:09:39 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 04/01/2003 12:05:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I don't mind skipping this Wed's telecon, either. Andrea Basso NMS Communications (732) 936-2118 |---------+----------------------------> | | Thomas Zeng | | | | | | Sent by: | | | | | | | | | | | | 03/31/2003 01:56 | | | PM | | | | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------| | | | To: "'Tom Marshall'" , Magnus Westerlund | | cc: IETF MMUSIC WG | | Subject: RE: [MMUSIC] RTSP teleconference, have or not? | >----------------------------------------------------------------------------------------------------------------| Happy Birtheday, Tom. I don't mind skipping this Wed's telecon, either. I am behind in RTSP related work after SF meetings. - thomas -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Monday, March 31, 2003 10:18 AM To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP teleconference, have or not? I would not mind cancelling or postponing the call, as it would be nice to be able to sleep in on my b'day. :-) On Mon, Mar 31, 2003 at 01:10:49PM +0200, Magnus Westerlund wrote: > Hi, > > It was planned to have a RTSP telecon on Wednesday (2 April). I am > somewhat short of time but I are willing to have this meeting at 18.00 > CET, which after having changed to daylight savings are GMT+2. As I > understand it US are changing to daylight saving next sunday and > therefore the conference will be one hour earlier than usual. This I > have heard is a bit difficult for the people on the US west cost. Due to > these considerations I would like to ask your opinion on what to do. Are > we going to: > 1. Cancel the meeting and having it next week instead? > 2. Have the meeting at the proposed time. > > Please send me your view before 12.00 tuesday (CET). -- Coding is easy; All you do is sit staring at a terminal until the drops of blood form on your forehead. -- Anonymous _______________________________________________ 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 mailnull@www1.ietf.org Tue Apr 1 12:30:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02044 for ; Tue, 1 Apr 2003 12:30:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31HsKX16376 for mmusic-archive@odin.ietf.org; Tue, 1 Apr 2003 12:54:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31HsKK16373 for ; Tue, 1 Apr 2003 12:54:20 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02001 for ; Tue, 1 Apr 2003 12:29:58 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Hs8K16341; Tue, 1 Apr 2003 12:54:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31Hr6K16032 for ; Tue, 1 Apr 2003 12:53:06 -0500 Received: from wullbinkle.real.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01896 for ; Tue, 1 Apr 2003 12:28:44 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2-glompatched/8.12.2) with ESMTP id h31HV0vm004005; Tue, 1 Apr 2003 09:31:00 -0800 Received: from [172.23.111.21] ([172.23.111.21]) by real.com (8.12.2-glompatched/8.12.2) with ESMTP id h31HV114029955; Tue, 1 Apr 2003 09:31:01 -0800 Subject: RE: [MMUSIC] RTSP teleconference, have or not? From: Rob Lanphier To: mmusic@ietf.org, Magnus WesterlundMagnusWesterlund In-Reply-To: References: Content-Type: text/plain Message-Id: <1049218292.24064.13.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.0 Date: 01 Apr 2003 09:31:32 -0800 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Agreed. Should we just plan on April 16 for our next call? Rob On Tue, 2003-04-01 at 09:09, Andrea Basso wrote: > I don't mind skipping this Wed's telecon, either. > > > Andrea Basso > NMS Communications > (732) 936-2118 > > > > |---------+----------------------------> > | | Thomas Zeng | > | | | | .com> | > | | Sent by: | > | | | | f.org> | > | | | > | | | > | | 03/31/2003 01:56 | > | | PM | > | | | > |---------+----------------------------> > >----------------------------------------------------------------------------------------------------------------| > | | > | To: "'Tom Marshall'" , Magnus Westerlund | > | cc: IETF MMUSIC WG | > | Subject: RE: [MMUSIC] RTSP teleconference, have or not? | > >----------------------------------------------------------------------------------------------------------------| > > > > > Happy Birtheday, Tom. > > I don't mind skipping this Wed's telecon, either. I am behind in RTSP > related work after SF meetings. > > - thomas > > > -----Original Message----- > From: Tom Marshall [mailto:tmarshall@real.com] > Sent: Monday, March 31, 2003 10:18 AM > To: Magnus Westerlund > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP teleconference, have or not? > > > I would not mind cancelling or postponing the call, as it would be nice to > be able to sleep in on my b'day. :-) > > On Mon, Mar 31, 2003 at 01:10:49PM +0200, Magnus Westerlund wrote: > > Hi, > > > > It was planned to have a RTSP telecon on Wednesday (2 April). I am > > somewhat short of time but I are willing to have this meeting at 18.00 > > CET, which after having changed to daylight savings are GMT+2. As I > > understand it US are changing to daylight saving next sunday and > > therefore the conference will be one hour earlier than usual. This I > > have heard is a bit difficult for the people on the US west cost. Due to > > these considerations I would like to ask your opinion on what to do. Are > > we going to: > > 1. Cancel the meeting and having it next week instead? > > 2. Have the meeting at the proposed time. > > > > Please send me your view before 12.00 tuesday (CET). > > -- > Coding is easy; All you do is sit staring at a terminal until the drops of > blood form on your forehead. > -- Anonymous > _______________________________________________ > 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 -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 1 15:17:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13179 for ; Tue, 1 Apr 2003 15:17:54 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h31Kfmd17166 for mmusic-archive@odin.ietf.org; Tue, 1 Apr 2003 15:41:48 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KfmK17163 for ; Tue, 1 Apr 2003 15:41:48 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13115 for ; Tue, 1 Apr 2003 15:17:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KfeK17136; Tue, 1 Apr 2003 15:41:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h31KetK17074 for ; Tue, 1 Apr 2003 15:40:55 -0500 Received: from gateus.nmss.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13009; Tue, 1 Apr 2003 15:16:28 -0500 (EST) Received: from NAMASMTP02 by gateus.nmss.com via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; 1 Apr 2003 15:14:11 UT Subject: RE: [MMUSIC] RTSP teleconference, have or not? To: Rob Lanphier Cc: Magnus WesterlundMagnusWesterlund , mmusic@ietf.org, mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Andrea Basso" Date: Tue, 1 Apr 2003 15:18:52 -0500 X-MIMETrack: Serialize by Router on NAMASMTP02/NMS Communications(Release 5.0.11 |July 24, 2002) at 04/01/2003 03:14:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 16 of April is fine with me. -A Andrea Basso NMS Communications (732) 936-2118 Rob Lanphier To: , Magnus WesterlundMagnusWesterlund Sent by: Subject: RE: [MMUSIC] RTSP teleconference, have or not? 04/01/2003 12:31 PM Agreed. Should we just plan on April 16 for our next call? Rob On Tue, 2003-04-01 at 09:09, Andrea Basso wrote: > I don't mind skipping this Wed's telecon, either. > > > Andrea Basso > NMS Communications > (732) 936-2118 > > > > |---------+----------------------------> > | | Thomas Zeng | > | | | | .com> | > | | Sent by: | > | | | | f.org> | > | | | > | | | > | | 03/31/2003 01:56 | > | | PM | > | | | > |---------+----------------------------> > > ----------------------------------------------------------------------------------------------------------------| > | | > | To: "'Tom Marshall'" , Magnus Westerlund | > | cc: IETF MMUSIC WG | > | Subject: RE: [MMUSIC] RTSP teleconference, have or not? | > > ----------------------------------------------------------------------------------------------------------------| > > > > > Happy Birtheday, Tom. > > I don't mind skipping this Wed's telecon, either. I am behind in RTSP > related work after SF meetings. > > - thomas > > > -----Original Message----- > From: Tom Marshall [mailto:tmarshall@real.com] > Sent: Monday, March 31, 2003 10:18 AM > To: Magnus Westerlund > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP teleconference, have or not? > > > I would not mind cancelling or postponing the call, as it would be nice to > be able to sleep in on my b'day. :-) > > On Mon, Mar 31, 2003 at 01:10:49PM +0200, Magnus Westerlund wrote: > > Hi, > > > > It was planned to have a RTSP telecon on Wednesday (2 April). I am > > somewhat short of time but I are willing to have this meeting at 18.00 > > CET, which after having changed to daylight savings are GMT+2. As I > > understand it US are changing to daylight saving next sunday and > > therefore the conference will be one hour earlier than usual. This I > > have heard is a bit difficult for the people on the US west cost. Due to > > these considerations I would like to ask your opinion on what to do. Are > > we going to: > > 1. Cancel the meeting and having it next week instead? > > 2. Have the meeting at the proposed time. > > > > Please send me your view before 12.00 tuesday (CET). > > -- > Coding is easy; All you do is sit staring at a terminal until the drops of > blood form on your forehead. > -- Anonymous > _______________________________________________ > 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 -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 02:30:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28060 for ; Wed, 2 Apr 2003 02:30:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h327sO111163 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 02:54:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327sOK11159 for ; Wed, 2 Apr 2003 02:54:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27753 for ; Wed, 2 Apr 2003 02:29:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327sFK11142; Wed, 2 Apr 2003 02:54:15 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h327rLK11065 for ; Wed, 2 Apr 2003 02:53:21 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27011 for ; Wed, 2 Apr 2003 02:28:41 -0500 (EST) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h327V9UE012370 for ; Wed, 2 Apr 2003 09:31:09 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A4KVL3K; Wed, 2 Apr 2003 09:31:09 +0200 Message-ID: <3E8A91BF.2030503@era.ericsson.se> Date: Wed, 02 Apr 2003 09:31:11 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP teleconference, have or not? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Okay, Next RTSP teleconference the 16th of April at 18.00 CET (GMT+2). Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 02:57:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29927 for ; Wed, 2 Apr 2003 02:57:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h328LOT13582 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 03:21:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328LOK13578 for ; Wed, 2 Apr 2003 03:21:24 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29915 for ; Wed, 2 Apr 2003 02:56:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328L7K13521; Wed, 2 Apr 2003 03:21:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328KnK13482 for ; Wed, 2 Apr 2003 03:20:49 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29882 for ; Wed, 2 Apr 2003 02:56:08 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h327waUE022242 for ; Wed, 2 Apr 2003 09:58:36 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A46RAJM; Wed, 2 Apr 2003 09:58:37 +0200 Message-ID: <3E8A982F.8050901@era.ericsson.se> Date: Wed, 02 Apr 2003 09:58:39 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP server behind NAT References: <3E88B59C.9080604@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I understand that there is interest to fix RTSP's NAT traversal capabilities to handle cases when both parties using private address spaces with NATs between them. This will require work from the one interested in this. With these assumptions you must also look into the problem of how to connect with TCP to the RTSP server in the first place. This seem to require RTSP proxies on the borders between different address domains. However I assume that a lot of these information can be had by looking how SIP solves the problem. I have some comments about TURN and RTSP. On the way to San Francisco I managed to analyze TURN and how it fits with RTSP. The major hurdle here is that the media destination address will be totally different from where the TCP connection comes from. If we are going to continue with our assumptions about when it is okay to send to another address we need the mechanism to determine that the destination accepts the data. When it comes to a solution of the problem of having servers on NATed addresses the ones doing the work will need to look into how to solves this problem. There seem to exist a couple of different ways to solve the problem. 1. Incorporate ICE into RTSP SETUP procedures. Includes need for doing multiple ICE rounds. This is similar to the Offer Answer problem for RTSP. 2. change RTSP to use SIP style session initiation. This work I think is similar to actually defining RTSP 2.0 and might be a rather grand work. I see need for having to determine which part of SIP that is needed. What extensions in SIP that will be needed to allow the media control part of RTSP to work as before. Also the whole integration between a normal conversational service and media control services needs to be looked into. I don't think it is a simple problem. Otherwise IETF would not have taken this time to even come close to a working conference solution. 3. Other alternatives. Does it exist other possible solutions? My conclusion is that the peer-to-peer RTSP over NATed networks will not be solved in a short time frame. And there is need to solve how to handle RTSP when only the client is in a private network. My proposal would be to progress the work simultaneously. I strongly believe that we can create something that work in time frame of the updated RTSP specification for public servers. There is of course important to align the work and ensure that either the whole public server work is a reusable for the peer-to-peer work, or at least does not create problems. I know that a single solution are normally better, but I think market forces will again make themselves remembered. Best Regards Magnus Jonathan Rosenberg wrote: > > > philippe.gentric@philips.com wrote: > > Magnus, I concur with Thomas, > > > > Since we have telephone handsets that can encode video in real time, > > Since we have PCs at home with WebCams, Since all these are behind > > NATs, Since multicast (and SSM) will not be > > available/desirable/permitted in many cases, We need to make sure > > that a RTSP server can exist in these environements, as RTSP is the > > obvious peer-to-peer video protocol to use. > > > > I suspect the key issue is that we have to assume that both end > > points (peers) are behind NATs and then I am afraid that the solution > > requires a "public" server in the middle. > > > > At this moment I suspect that TURN is one possible candidate(?) > > NATs on both sides does not always require a relay on the public > Internet. It only does if both NATs are symmetric. If at least one is > full cone, port restricted, etc., then the relay can be avoided. ICE > will make this determination for you, and only use TURN if > connectivity cannot be established directly. > > > > > Some kind of a "reversed" RTSP relay could also do the trick; > >> From the second peer (receiver of streams) point on view that relay > >> would be a plain RTSP server. > > The special trick is that the first peer (origin of streams) would > > need to contact this public gateway to "expose" that it has something > > to stream... And here comes the "reversed" weird stuff: That first > > peer acts as a RTSP server but it *initiates* the first TCP > > connection to the RTSP relay and that relay acts as a RTSP client but > > it is listening on some TCP port... > > > > It assumes that there is some way for the first peer to tell the > > second peer that the streams are available at that relay server. > > Email could do that, or a voice call, or pigeons ;-) > > > > Not sure if/how this is similar/different to what is intended with > > TURN ? > > TURN is similar, in that both sides need to rendezvous at a central > server. However, only one side needs to know about TURN. The other > will rendezvous by simply sending media to the TURN server. > > > > > > Jonathan can you explain what good TURN is supposed to do to RTSP ? > > It would support the case of the RTSP client and server both behind > separate, symmetric NAT. > > To support it, you need only make sure that RTSP allows the client to > specify the IP/port on which it will receive media. This is the same > thing you would need to do to support STUN. > > Getting back to this general issue of peer-to-peer RTSP, in my view > this is the ideal case to consider the model where SIP is used to > establish the session, and then RTSP is introduced for the control > aspects. This way, RTSP does not have to reinvent all the work that is > being done in SIP for nat/fw traversal, and all the applications where > the media streaming is integrated with person to person communications > is very easy. > > I think that there are no changes to RTSP to support this. We would > need some kind of SIP or SDP extensions to signal the usage of RTSP as > a control for another media stream, and then use SDP extensions to > pass any RTSP information needed to make this work (for example, the > session ID). > > Thoughts? > > -Jonathan R. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 02:57:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29954 for ; Wed, 2 Apr 2003 02:57:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h328M8f13748 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 03:22:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328M7K13745 for ; Wed, 2 Apr 2003 03:22:07 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29947 for ; Wed, 2 Apr 2003 02:57:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328M1K13715; Wed, 2 Apr 2003 03:22:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h328LjK13634 for ; Wed, 2 Apr 2003 03:21:45 -0500 Received: from albatross.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29922 for ; Wed, 2 Apr 2003 02:57:05 -0500 (EST) Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.8/8.12.8/WIREfire-1.5) with ESMTP id h327xXUE022619 for ; Wed, 2 Apr 2003 09:59:33 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2A46RA6J; Wed, 2 Apr 2003 09:59:34 +0200 Message-ID: <3E8A9868.1000103@era.ericsson.se> Date: Wed, 02 Apr 2003 09:59:36 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP teleconference, have or not? References: <3E8A91BF.2030503@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, And no RTSP meeting tonight/today. Best Regards Magnus Magnus Westerlund wrote: > Okay, > > Next RTSP teleconference the 16th of April at 18.00 CET (GMT+2). > > Best Regards > > Magnus Westerlund > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 05:15:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02758 for ; Wed, 2 Apr 2003 05:15:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32AdhY24894 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 05:39:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32AdgK24891 for ; Wed, 2 Apr 2003 05:39:42 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02732 for ; Wed, 2 Apr 2003 05:15:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32AdHK24833; Wed, 2 Apr 2003 05:39:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32AcVK24763 for ; Wed, 2 Apr 2003 05:38:31 -0500 Received: from relay1.clb.oleane.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02687 for ; Wed, 2 Apr 2003 05:13:49 -0500 (EST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by relay1.clb.oleane.net with SMTP id h32AGFo6014831 for ; Wed, 2 Apr 2003 12:16:16 +0200 Message-ID: <028f01c2f901$149fdda0$0601a8c0@oleane.com> From: "Peter Lewis" To: Date: Wed, 2 Apr 2003 12:17:35 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028C_01C2F911.D7D4C140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [MMUSIC] TVoDSL 2004 CONFERENCE Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_028C_01C2F911.D7D4C140 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TVoDSL 2004 CONFERENCE Broadcasting TV content over ADSL As ADSL access becomes more widespread, new markets for this technology = will start to materialize.=20 TV over ADSL is one of them. Major manufacturing, economic and = regulatory players in this area will share their experience at the = TVoDSL Conference, to take place in Paris on January 20 to 23, 2004.=20 =20 A call for proposal is online at: http://www.upperside.fr/tvodsl04/tvodsl04intro.htm ------=_NextPart_000_028C_01C2F911.D7D4C140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
TVoDSL 2004=20 CONFERENCE
Broadcasting TV = content over=20 ADSL

As ADSL=20 access becomes more widespread, new markets for this technology will = start to=20 materialize.
TV over ADSL is one of them. Major manufacturing, = economic and=20 regulatory players in this area will share their experience at the = TVoDSL=20 Conference, to take place in Paris on January 20 = to 23,=20 2004.
 
A call for proposal is online = at:
http://www.up= perside.fr/tvodsl04/tvodsl04intro.htm
------=_NextPart_000_028C_01C2F911.D7D4C140-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 13:21:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21782 for ; Wed, 2 Apr 2003 13:21:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32IjXP02343 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 13:45:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IjXK02340 for ; Wed, 2 Apr 2003 13:45:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21722 for ; Wed, 2 Apr 2003 13:20:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IjLK02281; Wed, 2 Apr 2003 13:45:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32IidK02215 for ; Wed, 2 Apr 2003 13:44:39 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21673; Wed, 2 Apr 2003 13:19:48 -0500 (EST) Message-Id: <200304021819.NAA21673@ietf.org> To: IETF-Announce: ; Cc: mmusic@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 02 Apr 2003 13:19:48 -0500 Subject: [MMUSIC] Last Call: RTCP attribute in SDP to Proposed Standard Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Multiparty Multimedia Session Control Working Group to consider RTCP attribute in SDP as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-4-14. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 14:07:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23456 for ; Wed, 2 Apr 2003 14:07:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32JW9506208 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 14:32:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JW9K06205 for ; Wed, 2 Apr 2003 14:32:09 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23445 for ; Wed, 2 Apr 2003 14:07:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JW5K06191; Wed, 2 Apr 2003 14:32:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32JQNK05852 for ; Wed, 2 Apr 2003 14:26:23 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23276 for ; Wed, 2 Apr 2003 14:01:30 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 190nWg-00020E-00 for ; Wed, 02 Apr 2003 11:03:58 -0800 Date: Wed, 2 Apr 2003 11:03:58 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030402190358.GA7450@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] RTSP ALGs, STUN, and destination parameter Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm writing an RTSP ALG for Linux iptables, and came across the problem of handling the destination parameter. There are several scenarios: 0. destination parameter not present. Not a problem. 1. Client is using STUN. destination parameter will be the client's internal address. It must not be rewritten, or streaming will fail. 2. Client is not using STUN, just being verbose. destination parameter will be the client's internal address. It must be rewritten to the external NAT address or stripped out, or streaming will fail. 3. Client wants the data to be sent somewhere else. destination parameter will not be the client's internal address. Three cases here: 3a. Client has dual nics. 3b. Client wants to send the data to another machine behind the NAT. 3c. Client wants to send the data to another machine on the internet. I don't think one can distinguish 3a and 3b so they can be considered as the same problem. The best way to deal with this case is probably to let the administrator decide with a security setting. Possible values are: - Always strip destination parameter. Not recommended. - Strip destination parameter if it does not match client's internal address. This is the default and recommended setting. - Never strip the destination parameter. Not recommended. This is all pretty straightforward so far. Now comes the tricky part. What to do with the address in the destination parameter as it passes through the NAT (assuming it's not stripped out)? I need a way to distinguish between cases 1 and 2 above to decide. If I arbitrarily choose to rewrite the address or not, the other case will be broken. Does anyone have any suggestions? --=20 Write a wise saying and your name will live forever. -- Anonymous --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+izQeqznSmcYu2m8RAkypAJ9QecPd+BGA9ptFYyVOPcKcCCEbpgCeLako spEszBbf+SdlJZuBgLBvxAg= =UN9H -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 17:11:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11941 for ; Wed, 2 Apr 2003 17:11:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32MaNW25359 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 17:36:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MaNK25356 for ; Wed, 2 Apr 2003 17:36:23 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11920 for ; Wed, 2 Apr 2003 17:11:27 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MaHK25332; Wed, 2 Apr 2003 17:36:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32MZZK25253 for ; Wed, 2 Apr 2003 17:35:35 -0500 Received: from mail3.dynamicsoft.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11897 for ; Wed, 2 Apr 2003 17:10:39 -0500 (EST) Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h32MD7Bd010201; Wed, 2 Apr 2003 17:13:08 -0500 (EST) Message-ID: <3E8B6066.80309@dynamicsoft.com> Date: Wed, 02 Apr 2003 17:12:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP ALGs, STUN, and destination parameter References: <20030402190358.GA7450@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I can't help pointing out that this kind of problem is exactly why ALGs are problematic. They are attempting to interpret the intention of the user so that they can "fix" the message to maintain the desired intention of the user in the presence of a nat. a more pragmatic comment inline: Tom Marshall wrote: > I'm writing an RTSP ALG for Linux iptables, and came across the problem > of > handling the destination parameter. There are several scenarios: > > 0. destination parameter not present. Not a problem. > > 1. Client is using STUN. > > destination parameter will be the client's internal address. > > It must not be rewritten, or streaming will fail. If the client is using STUN, the destination parameter will not be an internal address, it will be an external one. If the NAT knows which addresses are internal and which are external, it can differentiate case 1 from case 2 in this way. > > 2. Client is not using STUN, just being verbose. > > destination parameter will be the client's internal address. > > It must be rewritten to the external NAT address or stripped out, or > streaming will fail. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 2 17:39:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12728 for ; Wed, 2 Apr 2003 17:39:57 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h32N4Mw27547 for mmusic-archive@odin.ietf.org; Wed, 2 Apr 2003 18:04:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32N4MK27544 for ; Wed, 2 Apr 2003 18:04:22 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12688 for ; Wed, 2 Apr 2003 17:39:25 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32N4HK27531; Wed, 2 Apr 2003 18:04:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h32N3oK27507 for ; Wed, 2 Apr 2003 18:03:50 -0500 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12668 for ; Wed, 2 Apr 2003 17:38:53 -0500 (EST) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 190qv0-0002DG-00; Wed, 02 Apr 2003 14:41:18 -0800 Date: Wed, 2 Apr 2003 14:41:18 -0800 From: Tom Marshall To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP ALGs, STUN, and destination parameter Message-ID: <20030402224118.GC7450@real.com> References: <20030402190358.GA7450@real.com> <3E8B6066.80309@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <3E8B6066.80309@dynamicsoft.com> User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 02, 2003 at 05:12:54PM -0500, Jonathan Rosenberg wrote: > I can't help pointing out that this kind of problem is exactly why= =20 > ALGs are problematic. They are attempting to interpret the intention of= =20 > the user so that they can "fix" the message to maintain the desired=20 > intention of the user in the presence of a nat. Remember, STUN is a very new idea and it works by using some knowledge of common NAT implementations. Are going to volunteer to fix all the existing clients that are out in the field to use STUN and/or Symmetric RTP? ;-) Additionally, even if you have the asbolute best STUN (or Symmetric RTP) client and server imaginable, it is still possible that you won't be able to punch a hole in a NAT firewall. Why not? Because they depend on the NAT firewall setting up a "connection" when it sees outbound UDP packets. If the NAT firewall is sufficiently secure and it requires that UDP packets are related to an existing TCP connection, it won't work. > Tom Marshall wrote: > >I'm writing an RTSP ALG for Linux iptables, and came across the problem > >of > >handling the destination parameter. There are several scenarios: > > > >0. destination parameter not present. Not a problem. > > > >1. Client is using STUN. > > > > destination parameter will be the client's internal address. > > > > It must not be rewritten, or streaming will fail. >=20 > If the client is using STUN, the destination parameter will not be an=20 > internal address, it will be an external one. If the NAT knows which=20 > addresses are internal and which are external, it can differentiate case= =20 > 1 from case 2 in this way. Good idea. I'll see if this is possible, thanks. --=20 One is not superior merely because one sees the world as odious. -- Chateaubriand (1768-1848) --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+i2cOqznSmcYu2m8RAo/WAJ4/IVClSUx6Pp/llx4an9X8v+xKtQCfQvqB TLxAztO3xj8FN3CGultS73g= =Jjgu -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 3 15:11:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10575 for ; Thu, 3 Apr 2003 15:11:09 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33KDXD24492 for mmusic-archive@odin.ietf.org; Thu, 3 Apr 2003 15:13:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KDXK24489 for ; Thu, 3 Apr 2003 15:13:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10349 for ; Thu, 3 Apr 2003 15:10:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KDGK24447; Thu, 3 Apr 2003 15:13:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33KBmK24311 for ; Thu, 3 Apr 2003 15:11:48 -0500 Received: from ns2.packetvideo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10132 for ; Thu, 3 Apr 2003 15:08:48 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h33KBFqq098696; Thu, 3 Apr 2003 12:11:15 -0800 (PST) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Apr 2003 12:11:15 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A7965@MISTY> From: Thomas Zeng To: "'Magnus Westerlund'" , mmusic@ietf.org Subject: RE: [MMUSIC] RTSP server behind NAT Date: Thu, 3 Apr 2003 12:11:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus: On the high level, I agree that the first focus of RTSP taskforce should be to solve the easy problem: RTSP server in the open IP public network, clients are behind NAT. - thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Tuesday, April 01, 2003 11:59 PM To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP server behind NAT Hi, I understand that there is interest to fix RTSP's NAT traversal capabilities to handle cases when both parties using private address spaces with NATs between them. This will require work from the one interested in this. With these assumptions you must also look into the problem of how to connect with TCP to the RTSP server in the first place. This seem to require RTSP proxies on the borders between different address domains. However I assume that a lot of these information can be had by looking how SIP solves the problem. I have some comments about TURN and RTSP. On the way to San Francisco I managed to analyze TURN and how it fits with RTSP. The major hurdle here is that the media destination address will be totally different from where the TCP connection comes from. If we are going to continue with our assumptions about when it is okay to send to another address we need the mechanism to determine that the destination accepts the data. When it comes to a solution of the problem of having servers on NATed addresses the ones doing the work will need to look into how to solves this problem. There seem to exist a couple of different ways to solve the problem. 1. Incorporate ICE into RTSP SETUP procedures. Includes need for doing multiple ICE rounds. This is similar to the Offer Answer problem for RTSP. 2. change RTSP to use SIP style session initiation. This work I think is similar to actually defining RTSP 2.0 and might be a rather grand work. I see need for having to determine which part of SIP that is needed. What extensions in SIP that will be needed to allow the media control part of RTSP to work as before. Also the whole integration between a normal conversational service and media control services needs to be looked into. I don't think it is a simple problem. Otherwise IETF would not have taken this time to even come close to a working conference solution. 3. Other alternatives. Does it exist other possible solutions? My conclusion is that the peer-to-peer RTSP over NATed networks will not be solved in a short time frame. And there is need to solve how to handle RTSP when only the client is in a private network. My proposal would be to progress the work simultaneously. I strongly believe that we can create something that work in time frame of the updated RTSP specification for public servers. There is of course important to align the work and ensure that either the whole public server work is a reusable for the peer-to-peer work, or at least does not create problems. I know that a single solution are normally better, but I think market forces will again make themselves remembered. Best Regards Magnus Jonathan Rosenberg wrote: > > > philippe.gentric@philips.com wrote: > > Magnus, I concur with Thomas, > > > > Since we have telephone handsets that can encode video in real time, > > Since we have PCs at home with WebCams, Since all these are behind > > NATs, Since multicast (and SSM) will not be > > available/desirable/permitted in many cases, We need to make sure > > that a RTSP server can exist in these environements, as RTSP is the > > obvious peer-to-peer video protocol to use. > > > > I suspect the key issue is that we have to assume that both end > > points (peers) are behind NATs and then I am afraid that the solution > > requires a "public" server in the middle. > > > > At this moment I suspect that TURN is one possible candidate(?) > > NATs on both sides does not always require a relay on the public > Internet. It only does if both NATs are symmetric. If at least one is > full cone, port restricted, etc., then the relay can be avoided. ICE > will make this determination for you, and only use TURN if > connectivity cannot be established directly. > > > > > Some kind of a "reversed" RTSP relay could also do the trick; > >> From the second peer (receiver of streams) point on view that relay > >> would be a plain RTSP server. > > The special trick is that the first peer (origin of streams) would > > need to contact this public gateway to "expose" that it has something > > to stream... And here comes the "reversed" weird stuff: That first > > peer acts as a RTSP server but it *initiates* the first TCP > > connection to the RTSP relay and that relay acts as a RTSP client but > > it is listening on some TCP port... > > > > It assumes that there is some way for the first peer to tell the > > second peer that the streams are available at that relay server. > > Email could do that, or a voice call, or pigeons ;-) > > > > Not sure if/how this is similar/different to what is intended with > > TURN ? > > TURN is similar, in that both sides need to rendezvous at a central > server. However, only one side needs to know about TURN. The other > will rendezvous by simply sending media to the TURN server. > > > > > > Jonathan can you explain what good TURN is supposed to do to RTSP ? > > It would support the case of the RTSP client and server both behind > separate, symmetric NAT. > > To support it, you need only make sure that RTSP allows the client to > specify the IP/port on which it will receive media. This is the same > thing you would need to do to support STUN. > > Getting back to this general issue of peer-to-peer RTSP, in my view > this is the ideal case to consider the model where SIP is used to > establish the session, and then RTSP is introduced for the control > aspects. This way, RTSP does not have to reinvent all the work that is > being done in SIP for nat/fw traversal, and all the applications where > the media streaming is integrated with person to person communications > is very easy. > > I think that there are no changes to RTSP to support this. We would > need some kind of SIP or SDP extensions to signal the usage of RTSP as > a control for another media stream, and then use SDP extensions to > pass any RTSP information needed to make this work (for example, the > session ID). > > Thoughts? > > -Jonathan R. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 7 18:41:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09609 for ; Mon, 7 Apr 2003 18:41:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37MjcT20418 for mmusic-archive@odin.ietf.org; Mon, 7 Apr 2003 18:45:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37Mjb820415 for ; Mon, 7 Apr 2003 18:45:37 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09585 for ; Mon, 7 Apr 2003 18:40:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37MiU820387; Mon, 7 Apr 2003 18:44:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37MhB820342 for ; Mon, 7 Apr 2003 18:43:11 -0400 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09535 for ; Mon, 7 Apr 2003 18:38:16 -0400 (EDT) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 192fIF-0000Gd-00; Mon, 07 Apr 2003 15:40:47 -0700 Date: Mon, 7 Apr 2003 15:40:47 -0700 From: Tom Marshall To: mmusic@ietf.org Cc: Rob Lanphier Message-ID: <20030407224047.GC740@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] RTSP conntrack/nat module for Linux Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've written an RTSP conntrack/nat module for Linux's netfilter. Please see the url below for more information, including the download link: http://lists.netfilter.org/pipermail/netfilter-devel/2003-April/010949.html I would appreciate as much testing and feedback as possible. Thanks. --=20 A candidate is a person who gets money from the rich and votes from the poor to protect them from each other. -- Unknown --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+kf5vqznSmcYu2m8RAsi+AJ9pTMrqY6rIvRMh1Lm8gC6gbyO+tACfdt4m vxoM0UyxuCzXUQIsWl285p8= =uMpc -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 8 10:16:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12527 for ; Tue, 8 Apr 2003 10:16:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38ELU928955 for mmusic-archive@odin.ietf.org; Tue, 8 Apr 2003 10:21:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ELU828952 for ; Tue, 8 Apr 2003 10:21:30 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12458 for ; Tue, 8 Apr 2003 10:16:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EKF828763; Tue, 8 Apr 2003 10:20:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38EAO828290 for ; Tue, 8 Apr 2003 10:10:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10912; Tue, 8 Apr 2003 10:05:09 -0400 (EDT) Message-Id: <200304081405.KAA10912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 08 Apr 2003 10:05:09 -0400 Subject: [MMUSIC] I-D ACTION:draft-levin-mmusic-xml-media-control-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : XML Schema for Media Control Author(s) : O. Levin, S. Olson, R. Even Filename : draft-levin-mmusic-xml-media-control-02.txt Pages : 10 Date : 2003-4-7 This document defines an XML Schema for Media Control in a tightly controlled environment. The current version includes commands for managing of video streams only. Implementation of this schema for interactive video applications in SIP environments significantly improves user experience. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levin-mmusic-xml-media-control-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levin-mmusic-xml-media-control-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levin-mmusic-xml-media-control-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-7125234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levin-mmusic-xml-media-control-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-levin-mmusic-xml-media-control-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-7125234.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 8 14:09:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24382 for ; Tue, 8 Apr 2003 14:09:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h38IE6d16555 for mmusic-archive@odin.ietf.org; Tue, 8 Apr 2003 14:14:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IE6816552 for ; Tue, 8 Apr 2003 14:14:06 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24372 for ; Tue, 8 Apr 2003 14:08:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38ICS816510; Tue, 8 Apr 2003 14:12:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38IA7816409 for ; Tue, 8 Apr 2003 14:10:07 -0400 Received: from virago (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24249 for ; Tue, 8 Apr 2003 14:04:47 -0400 (EDT) Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 192xV9-0001Ll-00 for ; Tue, 08 Apr 2003 11:07:19 -0700 Date: Tue, 8 Apr 2003 11:07:19 -0700 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030408180719.GB4285@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WhfpMioaduB5tiZL" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] RTSP Connection header Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --WhfpMioaduB5tiZL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable rfc2326 defines the Connection header. I have some questions about implementation. 1. Table 3 says that the header is a general header, it is required to be supported, and it applies to all messages (presumedly this means both requests and responses). When is the server required to include a Connection header in a response? Always? At its discretion? When the client has sent one in the corresponding request? 2. Per section 12.10, the Connection header is defined in rfc2068 14.10. It says this: The Connection header has the following grammar: Connection-header =3D "Connection" ":" 1#(connection-token) connection-token =3D token HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option. What exactly does this mean? It appears to mean that if the proxy gets a message with "Connection: close, foo" and "foo: bar" headers, it must remove the "foo: bar" header. Is this correct? This says to me that we can have something like the following: Connection: Timed-Close Timed-Close: 30 The above (fictitious) example might indicate to a server that the client intends to close the control channel in 30 seconds. Is this a valid interpretation? What headers are excluded from this behavior (imagine someone sending "Connection: Content-Length")? --=20 You can complain because roses have thorns, or you can rejoice because thorns have roses. -- Abraham Lincoln --WhfpMioaduB5tiZL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+kw/XqznSmcYu2m8RAkGNAJ4lF0e4MjUVNreP5EZXnCzTOGvarQCeImYB Bq7L56oEJxwEeO6FmBQnma4= =hiT9 -----END PGP SIGNATURE----- --WhfpMioaduB5tiZL-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 9 00:46:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18425 for ; Wed, 9 Apr 2003 00:46:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h394pNu30844 for mmusic-archive@odin.ietf.org; Wed, 9 Apr 2003 00:51:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h394pN830841 for ; Wed, 9 Apr 2003 00:51:23 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18408 for ; Wed, 9 Apr 2003 00:45:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h394oG830807; Wed, 9 Apr 2003 00:50:16 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h394mU830762 for ; Wed, 9 Apr 2003 00:48:30 -0400 Received: from purple.nge.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18352 for ; Wed, 9 Apr 2003 00:42:56 -0400 (EDT) Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h394jSh0024825 for ; Wed, 9 Apr 2003 00:45:28 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304090445.h394jSh0024825@purple.nge.isi.edu> To: mmusic@ietf.org Date: Wed, 09 Apr 2003 00:45:28 -0400 From: Colin Perkins Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , I've just completed a detailed read-through the the key management extensions draft, and have a number of comments: - In section 3.1, first paragraph after bullet points on page 6, what happens if the key management protocol accepts the data in some attributes, and rejects the others? For example if a media level key management attribute is valid but the session level isn't? - In the second paragraph on page 8, does "The offer MUST then abort the security setup" mean that the entire session is aborted? Or does it go ahead without security? - I don't understand the discussion of resynchronization in the last paragraph of section 3.2. Can you clarify what is intended? - Given the risks identified in the third paragraph of section 5, it's not clear to me why the entire SDP message doesn't need to be authenticated? Are attacks possible by manipulating the non-authenticated parts of the SDP? I also have a number of editorial suggestions, which I'll forward to the authors. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 9 12:43:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05632 for ; Wed, 9 Apr 2003 12:43:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39Gn5d30044 for mmusic-archive@odin.ietf.org; Wed, 9 Apr 2003 12:49:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Gn5830041 for ; Wed, 9 Apr 2003 12:49:05 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05624 for ; Wed, 9 Apr 2003 12:43:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39Gmm830005; Wed, 9 Apr 2003 12:48:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39GkU829912 for ; Wed, 9 Apr 2003 12:46:30 -0400 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05516 for ; Wed, 9 Apr 2003 12:40:41 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h39GhEI3002225; Wed, 9 Apr 2003 18:43:14 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2TCX6J6P>; Wed, 9 Apr 2003 18:43:15 +0200 Message-ID: <1F55F6582266314A85A55F6241509B670575B332@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'Colin Perkins'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Date: Wed, 9 Apr 2003 18:39:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hi Colin, see comments inline. > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: den 9 april 2003 06:45 > To: mmusic@ietf.org > Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt > > > I've just completed a detailed read-through the the key management > extensions draft, and have a number of comments: > > - In section 3.1, first paragraph after bullet points on page 6, what > happens if the key management protocol accepts the data in some > attributes, and rejects the others? For example if a media level > key management attribute is valid but the session level isn't? > > - In the second paragraph on page 8, does "The offer MUST > then abort the > security setup" mean that the entire session is aborted? > Or does it go > ahead without security? To answer both these questions: session and media level failures should be treated the same way, i.e., the entire session is aborted (then it is up to the local policy to decide what to do). > > - I don't understand the discussion of resynchronization in the last > paragraph of section 3.2. Can you clarify what is intended? > Basically, if you need to change keys during an ongoing session, we propose to send a new INVITE message (with new crypto parameters inside). > - Given the risks identified in the third paragraph of > section 5, it's not > clear to me why the entire SDP message doesn't need to be > authenticated? I have never understood why people don't apply security to things :-) However, when it comes to SDP, the protection of the SDP will very much depend on the protocol carrying SDP and what security features are implemented (and defined as necessary). So it is out of the scope of this document to specify how to protect the SDP, and that is also why we only give a recommendation that you should apply some form of protection to the SDP. > Are attacks possible by manipulating the non-authenticated > parts of the > SDP? If you, by attacks, are referring to attacks towards the key management and the secured media, I would say no. Fredrik > > I also have a number of editorial suggestions, which I'll > forward to the > authors. > > Colin > _______________________________________________ > 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 mailnull@www1.ietf.org Wed Apr 9 18:27:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18330 for ; Wed, 9 Apr 2003 18:27:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39MWf502585 for mmusic-archive@odin.ietf.org; Wed, 9 Apr 2003 18:32:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MWe802581 for ; Wed, 9 Apr 2003 18:32:41 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18295 for ; Wed, 9 Apr 2003 18:26:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MUY802448; Wed, 9 Apr 2003 18:30:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h38HDT811935 for ; Tue, 8 Apr 2003 13:13:29 -0400 Received: from soleil.uvsq.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22445; Tue, 8 Apr 2003 13:07:54 -0400 (EDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.6/jtpda-5.4) with ESMTP id h38GvbI6062076 ; Tue, 8 Apr 2003 18:57:37 +0200 (CEST) Received: from BRUNE (brune.prism.uvsq.fr [193.51.25.132]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id h38GuX128152 ; Tue, 8 Apr 2003 18:56:33 +0200 (MET DST) Message-ID: <06d001c2fdf1$e17daa10$841933c1@BRUNE> From: "Ahmed Mehaoua" To: Cc: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , "\"Georg Carle\"" , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Date: Tue, 8 Apr 2003 19:10:50 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06CD_01C2FE02.914ABFE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [MMUSIC] CFP IEEE/IFIP Intern. Conference on Management of Multimedia Networks & Services 2003 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_06CD_01C2FE02.914ABFE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues,=20 Apologize for any duplicates; ------------------------------------------------------------------- Please distribute to interested people to encourage contributions ans = submissions to the 6th IFIP/IEEE International Conference on Management = of Multimedia Networks and Services : 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003 . ------------------------------------------------------------------- Please note the extension to the deadline for submission of papers to = MMNS2003 is 18th April 2003. Please circulate to your colleagues to = ensure a good turnout. For further information about the conference please see the web site at = http://ee-server.ee.qub.ac.uk/dsp/mmns2003/ Best Regards, Ahmed Mehaoua (Publicity chair) = -------------------------------------------------------------------------= -------------------------------- MMNS 2003 6th IFIP/IEEE International Conference on Management of Multimedia = Networks and Services 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003=20 Second Call For Papers Multimedia services over IP networks are proliferating at an enormous = speed. There=20 is also increasing demand for solutions which provide assured levels of = service quality.=20 All of these require novel paradigms, models and architectures for = realising integrated=20 end-to-end service management rather than managing network elements in = isolation.=20 Providing scalable Quality of Service (QoS) while maintaining fairness, = along with=20 secure and optimal network resource management are key challenges for = the future=20 Internet. These challenges apply to both fixed and wireless networks.=20 The IFIP/IEEE International Conference on Management of Multimedia = Networks and Services=20 will hold its sixth annual meeting from September 7th to September 10th, = 2003 in Belfast, Northern Ireland. MMNS provides an intimate setting for discussion and = debate. In just 6 years,=20 MMNS has established itself as one of the premier conferences with a = focus on the management=20 of multimedia networks and services. The conference objective is to = bring together researchers=20 working in all facets of network and service management as applied to = broadband networks and=20 multimedia services. MMNS deals with all aspects of designing, = developing and deploying=20 networked multimedia systems and it serves as a forum for the = dissemination of state-of-the-art=20 research and development results.=20 MMNS 2003 will also include panel sessions in which experts=20 offer their observations and opinions about current hot topics. The = keynote speaker will be=20 Professor Ian Akyildiz, Georgia Institute of Technology who will present = a vision of future=20 interplanetary network architectures. Professor Derek McAuley, head of = Intel's recently formed=20 laboratory at Cambridge, UK, will describe some of the new research = being undertaken on global=20 overlay networks and applications. The program committee is soliciting original papers describing research = in the area of=20 management of multimedia networks and services. Topics of interest = include, but are not=20 limited to, the following: * Active multimedia network management=20 * Ad-hoc and Sensor Networks=20 * Augmented and Virtual Reality Networks=20 * Billing and Accounting=20 * Cable multimedia network management=20 * Content distribution internetworking=20 * Deployment of multimedia services=20 * Distributed multimedia service management=20 * End-to-end IP multimedia network and service management=20 * IP Video, streaming, interactive video service management=20 * Middleware support for management=20 * Multimedia network traffic engineering and optimization=20 * Multimedia traffic management=20 * Multimedia content protection=20 * Multimedia session management=20 * Multi-point, multicast services management=20 * Network management models and architectures=20 * Network programmability for multimedia services=20 * Optical multimedia network management=20 * Policy-based management for multi-media services=20 * Provisioning of multimedia networks and services=20 * QoS in WLANs=20 * QoS management=20 * Resource, performance and fault management=20 * Security and Authentication=20 * VoIP service management=20 * Web Services=20 * Wireless and mobile multimedia network management=20 Papers must be submitted electronically in postscript or PDF format. = Detailed=20 instructions are provided on the conference web site, = http://www.ee.qub.ac.uk/mmns2003.=20 Submission date: 18th April 2003 Notification of acceptance: 6th June 2003 Final version: 4th July 2003 Conference Chairs: Professor Alan Marshall, a.marshall@ee.qub.ac.uk, Queen's University = of Belfast, UK Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of Evry, = France Qiang Gu Advanced Telecommunication Systems Laboratory School of Electrical & Electronic Engineering The Queen's University of Belfast Belfast Northern Ireland. BT9 5AH Email: qiang.gu@ee.qub.ac.uk Telephone: +44 -2890-274142 Fax: +44 -2890-274417 --------------------------------------------------------- Ahmed Mehaoua University of Versailles - CNRS PRISM Lab. 45 av. des etats unis 78000 Versailles - France Email : mea@prism.uvsq.fr Tel : +33 1 39 25 40 45 ------=_NextPart_000_06CD_01C2FE02.914ABFE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
Apologize for any=20 duplicates;
 
----------------------------------------------------------------= ---

 Please=20 distribute to interested people to encourage contributions ans = submissions to=20 the 6th IFIP/IEEE International = Conference on=20 Management of Multimedia Networks and Services=20 :
        7th - 10th September = 2003,=20 Queen's University of Belfast, Northern Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns200= 3=20 .
----------------------------------------------------------------= ---
Please note the extension to the = deadline for=20 submission of papers to MMNS2003 is 18th=20 April 2003. Please circulate to your colleagues to ensure a good=20 turnout.
 
For further information about the = conference please=20 see the web site at http://ee-server.ee.= qub.ac.uk/dsp/mmns2003/
 
Best Regards,
 
Ahmed Mehaoua
(Publicity chair)
 
 
 ----------------------------------------------------------= -----------------------------------------------
 
MMNS 2003
6th = IFIP/IEEE=20 International Conference on Management of Multimedia Networks and=20 Services
        7th - 10th = September=20 2003, Queen's University of Belfast, Northern Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns200= 3=20
 

          &nbs= p;            = ;          =20 Second Call For Papers
 
Multimedia services over IP networks are proliferating at an = enormous=20 speed. There
is also increasing demand for solutions which provide = assured=20 levels of service quality.
All of these require novel paradigms, = models and=20 architectures for realising integrated
end-to-end service management = rather=20 than managing network elements in isolation.
Providing scalable = Quality of=20 Service (QoS) while maintaining fairness, along with
secure and = optimal=20 network resource management are key challenges for the future =
Internet.=20 These challenges apply to both fixed and wireless networks.
 
The IFIP/IEEE International Conference on Management of Multimedia = Networks=20 and Services
will hold its sixth annual meeting from September 7th = to=20 September 10th, 2003 in Belfast,
Northern Ireland. MMNS provides an = intimate=20 setting for discussion and debate. In just 6 years,
MMNS has = established=20 itself as one of the premier conferences with a focus on the management =
of=20 multimedia networks and services. The conference objective is to bring = together=20 researchers
working in all facets of network and service management = as=20 applied to broadband networks and
multimedia services. MMNS deals = with all=20 aspects of designing, developing and deploying
networked multimedia = systems=20 and it serves as a forum for the dissemination of state-of-the-art =
research=20 and development results.
 
MMNS 2003 will also include panel sessions in which experts =
offer their=20 observations and opinions about current hot topics. The keynote speaker = will be=20
Professor Ian Akyildiz, Georgia Institute of Technology who will = present a=20 vision of future
interplanetary network architectures. Professor = Derek=20 McAuley, head of Intel's recently formed
laboratory at Cambridge, = UK, will=20 describe some of the new research being undertaken on global
overlay = networks and applications.
 

The program committee is soliciting original papers describing = research=20 in the area of
management of multimedia networks and services. = Topics of=20 interest include, but are not
limited to, the following:
 
        * Active multimedia = network=20 management
        * Ad-hoc and = Sensor=20 Networks
        * Augmented and = Virtual=20 Reality Networks
        * = Billing and=20 Accounting
        * Cable = multimedia=20 network management
        * = Content=20 distribution internetworking =
        *=20 Deployment of multimedia services =
       =20 * Distributed multimedia service management=20
        * End-to-end IP = multimedia=20 network and service management =
        *=20 IP Video, streaming, interactive video service management=20
        * Middleware support for=20 management
        * Multimedia = network=20 traffic engineering and optimization=20
        * Multimedia traffic = management=20
        * Multimedia content = protection=20
        * Multimedia session = management=20
        * Multi-point, multicast = services=20 management
        * Network = management=20 models and architectures
        = *=20 Network programmability for multimedia services=20
        * Optical multimedia = network=20 management
        * Policy-based = management for multi-media services=20
        * Provisioning of = multimedia=20 networks and services
        * = QoS in=20 WLANs
        * QoS management=20
        * Resource, performance = and fault=20 management
        * Security and = Authentication
        * VoIP = service=20 management
        * Web Services =
        * Wireless and mobile = multimedia=20 network management
 

Papers must be submitted electronically in postscript or PDF = format.=20 Detailed
instructions are provided on the conference web site, http://www.ee.qub.ac.uk/mmns200= 3.=20
 
Submission=20 date:            = 18th=20 April 2003
Notification of acceptance: 6th June 2003
Final=20 version:           = ;  =20 4th July 2003
 
Conference Chairs:
   Professor Alan Marshall, a.marshall@ee.qub.ac.uk, = Queen=92s=20 University of Belfast, UK
   Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of = Evry,=20 France
 
Qiang Gu
Advanced Telecommunication = Systems=20 Laboratory
School of Electrical & Electronic Engineering
The = Queen's=20 University of Belfast
Belfast
Northern Ireland.
BT9 = 5AH
Email: qiang.gu@ee.qub.ac.uk
Teleph= one: +44=20 -2890-274142
Fax: +44 -2890-274417
---------------------------------------------------------
Ahm= ed=20 Mehaoua
University of Versailles - CNRS PRISM Lab.
45 av. des = etats unis=20 78000 Versailles - France
Email : mea@prism.uvsq.fr
Tel : +33 1 = 39 25 40=20 45
 
 
------=_NextPart_000_06CD_01C2FE02.914ABFE0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 9 18:29:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18437 for ; Wed, 9 Apr 2003 18:28:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h39MY2F02674 for mmusic-archive@odin.ietf.org; Wed, 9 Apr 2003 18:34:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MXY802652 for ; Wed, 9 Apr 2003 18:33:34 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18290 for ; Wed, 9 Apr 2003 18:26:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39MUu802472; Wed, 9 Apr 2003 18:30:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h39CXb808225 for ; Wed, 9 Apr 2003 08:33:37 -0400 Received: from infres.enst.fr (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25485; Wed, 9 Apr 2003 08:26:52 -0400 (EDT) Received: from brigitte.enst.fr (dhcp192-240.enst.fr [137.194.192.240]) by infres.enst.fr (Postfix) with ESMTP id 387CA18C0; Wed, 9 Apr 2003 14:28:02 +0200 (MEST) Message-Id: <5.1.1.6.0.20030409115737.01fdbc90@pop.infres.enst.fr> X-Sender: gagnaire@pop.infres.enst.fr X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 09 Apr 2003 14:33:30 +0200 To: , , , , , , , , , , , , , , , , , , , , , , , , , , Silvano Gai , Francesco Masetti , enrica filippi , Colombo Giovanni , Roberto Sabella , "Dr. Heinrich J. Stuettgen" , Enrico gregori , Battiti Roberto , James Roberts , Maurice Gagnaire , "Dr. Mounir Hamdi" , Achille Pattavina , Adam Wolisz , BONA Alberto , Andrea Francini , Anna Banfi , Anna Marcogliese , Annie Gravey , Antonio Iera , Antonio Nucci , Ariel Orda , Tentov Aristotel , Arne Svensson , Begain , Bijan Jabbari , Bob Borri , Boudewijn Haverkort , breslau , Cauligi Raghavendra , Chris Blondia , christophe diot , Clarence Filsfils , Claude Castelluccia , crovella , cruz , "Denis A. Khotimsky" , Krys Pawlikowski , Dimitrios Stiliadis , "Dr. Anthony Acampora" , Edward Knightly , "Eitan.Altman" , erbi , Erina Ferro , Eugenio Costamagna , "modiano@mit.edu" , Fabio Chiussi , "George C. Polyzos" , Giacomazzi , Gianluca Reali , Gianni Immovilli , Gino Menchi , Giordana Lisa , Giorgio Gallassi , giovanni , Giovanni Ferrero , Giovanni Pau , Giuseppe Giacobbo Scavo , Guarene Eugenio , Harmen van As , Harry Rudin , Henning Schulzrinne , "Ian F. Akyildiz" , istoica , "Izhak Rubin (E-mail)" , jereb , Jonathan Billington , Josep Sole-Pareta , "Karl.A.Lindberger" , killat , kuehn , LAURA BRAGAGIA , leandros , Luciano Lenzini , Luigi Licciardi , Mario Baldi , Masayuki Murata , Maurizio Casoni , Maurizio Pignolo , "mecocci@dii.unisi.it" , Menolascino Raffaele , "Milena Butto'" , mk , Eytan Modiano , Moshe Zukerman , Naoaki Yamanaka , Nelson Fonseca , Nicola Blefari-Melazzi , Osvaldo Telese , "P.F. Chimento" , padhye , "paolo.castelli" , "Papavassiliou, Symeon" , PERINO Massimo , peterkey , "Philip E. Rynes" , "Prof. P. Tran-Gia" , PROIETTI Mauro , "r.j.gibbens" , Rajeev Shorey , Rajiv Ramaswami , Ramon Puigjaner , "Raymond.Marie" , Richard Reeves , "roberto.campagnola@accenture.com" , Roffinella Daniele , Sandor Molnar , Sandra Tartarelli , Santosh Krishnan , Saverio Mascolo , "segall@ee.technion.ac.il" , "Serge.Fdida" , Sergio TREVES , Serpanos Dimitris , Sikdar , Stephen Pink , suda , Sundar Iyer , "T. V. Lakshman" , Tetsuya Takine , Tulin Atmaca , "udo.krieger" , Victor Frost , Viktoria Fodor , Walter Willinger , Wojciech Burakowski , yener , Yoram Ofek , Yuji OIE , Hideaki Takagi , Yutaka Takahashi From: Maurice GAGNAIRE Cc: , , , , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] CFP of Internetworking 2003 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , With our apologize for any duplicates; ********************************************************** INTERNETWORKING 2003 International Conference Hilton San Jose & Towers Hotel, California Sunday June 22 through Tuesday June 24, 2003 with the support of the IEEE and IFIP WG 6.2 ********************************************************** Internetworking-2003 is a conference focused on internetworking technologies in the IP, optical, and wireless domains. Last year's event was collocated with the highly successful MPLS 2002 conference, which was held in Washington DC. Internetworking 2003 is more expansive than the MPLS conference series and encompasses a wider range of topics. The Internetworking 2003 event in March will include participation from industry, government agencies, and the academia. Presentations are through invitation and via open call.Technical sessions at the conference include the following tracks: - Routing - OSS and Network Management - Virtual Private Networks (VPNs) - IP Network Security - Voice over IP - IPv6 Call For Papers: ---------------- The Internetworking 2003 Program Committee cordially invites you to submit proposals for original, unpublished presentations focusing on internetworking technologies in the IP, optical, and wireless domains. Summaries not exceeding 250 words can be submitted to submissions@caitr.org for review and possible inclusion in the program, no later than April 11, 2003. Topics of interest include, but are not limited to the following: * Voice over IP (VoIP) * IP Video Conferencing * Storage Area Networks (SANs) * Unicast and Multicast Routing and Convergence * QoS Routing * Network Security and Service Integration * Operational Support Systems * Virtual Private Networks * Internetworking Wireless LANs and 3G Wireless Networks * IP-based Infrastructure for Wireless Networks * Internetworking IP and Optical Networks * Internetworking MPLS with Legacy ATM and Frame Relay Networks * Transition from IPv4 to IPv6 and interworking * Pervasive Computing * High Speed Transport Layer Protocols * Peer to Peer Networking and Grid Computing * Video Teleconferencing (VTC) * 802.11 Hotspots * Ethernet First Mile networks (EPON, EDSL) * IEEE 802.17 MAN, RPR Conference Web_site: http://www.caitr.org/internetworking03/program.htm -------------------- Technical Programme Committee : -------------------------------------------- - Maurice Gagnaire (ENST- France) co-chair - Daniel Awduche (Isocore - USA) co-chair - Augusto Casaca (INESC- Portugal) - Nada Golmie (NIST - USA) - Ibrahim Habib (CUNY - USA) - Bijan Jabbari (GMU - USA) - Marc Lobelle (UCL - Belgium) - Fabio Neri (Politecnico di Torino - Italy) * - Guy Pujolle (LIP6 - France) - James Roberts (France Telecom R&D) * - Roberto Sabella (Erisson - Italy) - Jochen H. Schiller (Freie Univ. Berlin, Germany) - Vishal Sharma (Metanoia - USA) - Samir Tohme (ENST - France) - Stefano Trumpy (CNR - Italy) - Peter Vetter (Alcatel Antwerpen - Belgium) * - Parviv Yegani (Cisco - USA) - Ferit Yegenoglu (Isocore -USA) - Ali Zadeh (GMU - USA) - Moshe Zukerman (Univ. of Melbourne - Australia) (* = to be confirmed) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sat Apr 12 16:15:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04132 for ; Sat, 12 Apr 2003 16:15:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3CKMXX20545 for mmusic-archive@odin.ietf.org; Sat, 12 Apr 2003 16:22:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CKMW820542 for ; Sat, 12 Apr 2003 16:22:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04129 for ; Sat, 12 Apr 2003 16:15:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194RRc-0002QG-00 for mmusic-web-archive@ietf.org; Sat, 12 Apr 2003 16:17:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194RRb-0002QC-00 for mmusic-web-archive@ietf.org; Sat, 12 Apr 2003 16:17:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CKMP820534; Sat, 12 Apr 2003 16:22:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3CKLW820510 for ; Sat, 12 Apr 2003 16:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04124 for ; Sat, 12 Apr 2003 16:14:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194RQe-0002Q8-00 for mmusic@ietf.org; Sat, 12 Apr 2003 16:16:48 -0400 Received: from wireless248.east.isi.edu ([65.123.202.248] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 194RQc-0002Q4-00 for mmusic@ietf.org; Sat, 12 Apr 2003 16:16:48 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3CKGkmI002359; Sat, 12 Apr 2003 16:16:46 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304122016.h3CKGkmI002359@purple.nge.isi.edu> To: "Fredrik Lindholm (EAB)" cc: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt In-Reply-To: Your message of "Wed, 09 Apr 2003 18:39:30 +0200." <1F55F6582266314A85A55F6241509B670575B332@Esealnt863.al.sw.ericsson.se> Date: Sat, 12 Apr 2003 16:16:46 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> "Fredrik Lindholm (EAB)" writes: > >Hi Colin, > >see comments inline. > >> -----Original Message----- >> From: Colin Perkins [mailto:csp@csperkins.org] >> Sent: den 9 april 2003 06:45 >> To: mmusic@ietf.org >> Subject: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt >> >> >> I've just completed a detailed read-through the the key management >> extensions draft, and have a number of comments: >> >> - In section 3.1, first paragraph after bullet points on page 6, what >> happens if the key management protocol accepts the data in some >> attributes, and rejects the others? For example if a media level >> key management attribute is valid but the session level isn't? >> >> - In the second paragraph on page 8, does "The offer MUST >> then abort the >> security setup" mean that the entire session is aborted? >> Or does it go >> ahead without security? > >To answer both these questions: session and media level failures >should be treated the same way, i.e., the entire session is >aborted (then it is up to the local policy to decide what to do). Okay. The draft needs clarification though. >> - I don't understand the discussion of resynchronization in the last >> paragraph of section 3.2. Can you clarify what is intended? >> > >Basically, if you need to change keys during an ongoing session, >we propose to send a new INVITE message (with new crypto parameters >inside). Again, okay but the text needs to be clarified. >> - Given the risks identified in the third paragraph of >> section 5, it's not >> clear to me why the entire SDP message doesn't need to be >> authenticated? > >I have never understood why people don't apply security to things :-) >However, when it comes to SDP, the protection of the SDP will >very much depend on the protocol carrying SDP and what security >features are implemented (and defined as necessary). So it is out >of the scope of this document to specify how to protect the SDP, >and that is also why we only give a recommendation that you should >apply some form of protection to the SDP. But if the SDP has to be transferred by a secure channel, what is the point of MIKEY? >> Are attacks possible by manipulating the non-authenticated >> parts of the >> SDP? > >If you, by attacks, are referring to attacks towards the key management >and the secured media, I would say no. But is may be possible to redirect a media stream, for example? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sun Apr 13 18:16:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07824 for ; Sun, 13 Apr 2003 18:16:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3DMNPA20518 for mmusic-archive@odin.ietf.org; Sun, 13 Apr 2003 18:23:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMNP820515 for ; Sun, 13 Apr 2003 18:23:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07776 for ; Sun, 13 Apr 2003 18:15:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194pnb-0006QQ-00 for mmusic-web-archive@ietf.org; Sun, 13 Apr 2003 18:18:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194pna-0006QM-00 for mmusic-web-archive@ietf.org; Sun, 13 Apr 2003 18:18:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMNJ820507; Sun, 13 Apr 2003 18:23:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3DMJh820416 for ; Sun, 13 Apr 2003 18:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07412 for ; Sun, 13 Apr 2003 18:11:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194pk2-0006Pz-00 for mmusic@ietf.org; Sun, 13 Apr 2003 18:14:26 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 194pjy-0006Pv-00 for mmusic@ietf.org; Sun, 13 Apr 2003 18:14:23 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3DMEPOJ004578 for ; Sun, 13 Apr 2003 18:14:25 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304132214.h3DMEPOJ004578@purple.nge.isi.edu> To: mmusic@ietf.org Date: Sun, 13 Apr 2003 18:14:25 -0400 From: Colin Perkins Subject: [MMUSIC] Draft minutes from San Francisco Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Enclosed are draft minutes from MMUSIC in San Francisco. These need to be submitted by tomorrow (Monday 14th), so please send any comments quickly. Copies of the minutes and presentation materials are available at http://www.dmn.tzi.org/ietf/mmusic/ Colin =============================================================================== Multipary Multimedia Session Control (MMUSIC) Working Group Minutes Reported by Colin Perkins The MMUSIC working group met once at the 56th IETF meeting in San Francisco. The group discussed connection oriented media, various SDP extensions, Offer/Answer examples, SDPng, Internet Media Guides, and RTSP. Introduction and Status Update Joerg Ott began the meeting with an introduction and status update. One RFC has been published since the last meeting (RFC 3388 on Flow Identification), and one draft is with the RFC Editor (draft-ietf- mmusic-reservations-flows-01.txt). The revision to SDP (draft-ietf- mmusic-sdp-new-12.txt) is under AD review, as are drafts in the RTCP attribute in SDP (draft-ietf-mmusic-sdp4nat-03.txt) and the SDPng Transition Strategies (draft-ietf-mmusic-sdpng-trans-03.txt). The SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-01.txt) are in working group last call, and comments are solicited. Joerg noted that the SDP specification has been revised due to Area Director feedback. Colin Perkins described the changes: a number of minor fixes to the ABNF, and significant updates to the description of the "k=" field and the IANA Considerations section. The registration requirements for attributes and other parameters have been significantly tightened with this revision, and comments are solicited regarding the degree to which these changes are appropriate. The SDP source filter draft (draft-ietf-mmusic-srcfilter-03.txt) is essentially complete, just needing editorial work. The chairs noted that they expect to issue working group last call on this in early April, and that anyone with comments should post them shortly. There is a new draft on SDP implementation status and interoperability (draft-ietf-mmusic-sdp-implem-00.txt), which is a first cut at the documentation needed to advance SDP to draft standard. Please read and comment. The working group has completed its charter, and a draft for a revised charter was sent to the mailing list prior to the meeting. This draft is under discussion between the chairs and area director, and comments are solicited from the group. It is expected that the revision will include work on SDP, SDPng, RTSP and Internet Media Guides. Conference Control has been ruled out of scope at this time. Connection-Oriented Media Transport in SDP David Yon discussed comedia (draft-ietf-mmusic-sdp-comedia-05.txt). The changes in -05 include removal of source address/port per discussion on the mailing list, and removal of the current security considerations in preparation for a revision in the next version (again, as discussed on the mailing list). David noted that the main security issue is session hijacking, which can be solved by using secure media streams. In the absence of this, the attack can be downgraded to a denial of service, if the endpoints follow the rules in Section 4(b) and (c) of the draft, using duplicate incoming connections as a signal of the attack (this works for TCP and bidirectional RTP). Jonathan Rosenberg noted that using double connect as an indication of an attack might fail in the presence of forking invites; this needs further consideration. Next steps are to come to closure on the RTSP issues discussed on the mailing list, and to fold in the expanded security considerations into -06. Colin Perkins confirmed that the "eid" would be implemented as a separate draft if needed. David expressed the hope that the -06 version would be ready for working group last call. SDP key management extensions Elisabetta Carrara discussed changes to the key management extensions work (draft-ietf-mmusic-kmgmt-ext-07.txt). The changes are primarily for clarification, and include a more detailed description of the interactions between SDP and the key management module, and rekeying. In addition, the IANA considerations section has been updated. The main issue previously noted was a bidding down attack, which Elisabetta described, but this has been solved in -07 by authenticating the list of proposed key management protocols in the SDP. Mark Baugher noted that another way to avoid the attack is to use only a single key management protocol, to avoid the possibility of bidding. Ran Canetti described how the attack is still valid in that case, since the bid down can be done over multiple INVITEs with different protocols meaning that the addition of authentication is the correct solution (even though it complicates the protocol). It was asked if Kerberos still works with the changes? Elisabetta said it should, but she would check to make sure. Colin Perkins noted that approval is needed from the transport area security advisor before this draft can advance, but that the changes appear to address the previously open issues. SDP Security Descriptions for Media Streams Mark Baugher discussed SDP security descriptions for media streams (draft-ietf-mmusic-sdescriptions-00.txt). The aim of this draft is to replace k= with an attribute, suitable for signalling SRTP parameters. The draft is intended for applications where the signalling channel is secure. If the signalling is hop-by-hop, as is common with telephony, the intermediate hops must be trusted to maintain security. Changes from (draft-baugher-mmusic-sdpmediasec-00.txt) apply parameters to media streams, not codecs (see discussion at the previous meeting); apply parameters to the SDP media level only (as a result of improving offer/answer); add an "application" parameter allowing separate descriptions for SRTP and SRTCP; define use with offer/answer and augment the ABNF. Next steps are to fix known problems, in particular the ambiguities with SDP direction attributes, to generalize offer/answer, and to generalize to transports beyond SRTP, and to get implementation experience. Magnus Westerlund noted that RTSP doesn't currently define a secure signalling channel. This will need to be fixed, if this work is to be used with RTSP. Steve Casner asked if the semantics were well defined if more than one of "k=", "a=keymgmt", and "a=crypto" are present? This is not legal, but appropriate behaviour needs to be specified. It was asked how a system should behave if the key is referenced by a non-secure URI? This is clearly not appropriate use. SDP attribute for qualifying media formats with generic parameters Flemming Andreasen discussed (draft-rajeshkumar-mmusic-gpmd-02.txt). This is intended to provide an alternative to "a=fmtp:", so that new parameters can be added to existing media formats. The example being a voice-band data parameter, to apply to codecs such as PCMU when used for modem or fax relay. Changes since -01 are to firm up the definition of the gpmd attribute, clarifying that it is intended for informative hints, and that lack of a gpmd parameters MUST NOT render the media format useless. Use with offer/answer has also been specified, as have registration procedures. Ruediger Kreuter asked if an echo cancellor parameter has been considered? Flemming replied that there are many ways of specifying this - see V.150 - how should it be specified? Colin Perkins noted that this should be a new extension draft, rather than being including in the gpmd draft, to avoid delaying the work. The chairs asked for comments, noting that they intend to issue a working group last call on this draft shortly. SDP Offer/Answer Examples Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-01.txt which provides examples of the use of the offer/answer model. There have been a number of minor corrections and clarifications since the -00 draft, and the plan is to continue collecting new scenarios and seek review and comment from implementors. If you are implementing SIP and offer/answer, you are urged to review the draft and send feedback. SDPng Update Dirk Kutscher presented an update on the SDPng work (draft-ietf-mmusic- sdpng-06.txt). Changes in -06 include a new document structure, new requirements for capability specifications, new capability negotiation rules, the removal of XML-Schema-based formal definitions and text on session-level information. Capability specifications are now required to support feature independent negotiation and must not require access to a package definition in order to process capability descriptions. This requires definition of a fixed set of basic types, encoding the type into values. In addition, names must be fully qualified. Capability negotiation rules have been updated to describe the general behaviour, leaving concrete behaviour implementation specific. Two alternative procedures are specified: an offer/answer based scheme and an RFC 2533 (conneg) style approach. Open issues include a concrete syntax definition, session level data, and possible use of libraries of definitions. Next steps are to give details on describing actual configurations and transport parameters, and a formal definition mechanisms for packasges. Other work items include specific package definitions (e.g. audio, video) and session level metadata. Internet Media Guides Rod Walsh outlined Internet Media Guides (IMGs), a potential new work item for the group. An Internet Media Guide (IMG) is a collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. It is used to describe a collection of multimedia sessions (e.g. television programme schedules). The IMG must be delivered to a potentially large audience, who use it to join a subset of the sessions described, and who may need to be notified of changes to the IMG. This problem lends itself to solution by (extensions of) some existing mechanisms: SAP and SDP/SDPng. MMUSIC therefore seems the natural home for the work. Other groups (e.g. DVB-IPI, TV Anytime, and the IP datacast forum) have identified similar needs, but do not have the experience to solve the problem. The chairs presented some initial charter text discussing the problem (subject to modification/approval from the area directors) and asked if the working group considered this an appropriate work item? Strong support was received. RTSP Magnus Westerlund discussed changes to the Real Time Streaming Protocol (draft-ietf-mmusic-rfc2326bis-03.txt). The goal is to update and clarify the RTSP specification, with the aim of moving to draft standard RFC (a new proposed standard RFC may be required first, depending on the scale of the changes). The aim is to have the core specification completed by October 2003. The new version will be a minimal core specification, with extensions documents for NAT traversal, MUTE and UNMUTE and (possibly) a MIB, RECORD, secure RTSP, and RTSP over unreliable transport. Since the previous meeting, there have been 5 teleconferences discussing the spec (details announce on the mailing list or see http://rtsp.org/). A list of known bugs in the specification is also maintained at http://rtspspec.sourceforge.net/. Changes updates discussed recently include: - Non-persistent connection support is now mandatory - IPv6 support added - Accept-Ranges as proposed in the core spec - Byte ranges will be allowed - Via header will not be changed to include client address - Clarification of 304 "Not modified" - Clarification of redirection - Agreed feature extension mechanism - Strengthened requirements for Destination header - Added source and destination addresses to the Transport header - RTP-Info's base URL is a PLAY request URL - Clarified interleaved usage - A SETUP to change transport parameters leaves the previous state intact if it fails - Clarification that RTSP URLs are case sensitive - Range header now required in all PLAY responses - Range is formulated as start point (inclusive) to stop point (non-inclusive) - Use of PAUSE when in Ready clarified Open issues include how RTSP extensions registrations are to be handled, and what are the requirements for new extensions; can timed requests be removed; handling of multiple SSRCs in RTSP; and inclusion of a warning header. Input from those working with RTSP was sought, since there is a shortage of manpower on this effort. RTSP and NAT Magnus Westerlund discussed NAT traversal for RTSP (draft-ietf-mmusic- rtsp-nat-00.txt). The issue is not RTSP signalling itself, but how the media streams traverse the NAT, and how RTSP knows the correct external addresses to use after NAT traversal. Will also address cooperation with firewalls. The draft currently discusses use of STUN, symmetric RTSP, tunnelled media in TCP and application level gateways. Open issues exist with the use of STUN for symmetric NATs and symmetric RTP. Mark Baugher asked if the authors have considered potential issues with secure RTSP? May not be as simple as "just use SSL"? Philippe Gentric noted that the attacker is often the client, so a secure channel may not help security. Magnus asked for input, and is seeking a co-author to help complete the work. Stream Switching Control Philippe Gentric discussed draft-gentric-mmusic-stream-switching-00.txt, a new draft describing how a server can signal that it is switching from one version of a stream to another (for example, for coarse-grained rate adaptation, when the limits of adaptation of a particular codec are exceeded). Alan Duric was glad to see the work, but asked if Philippe considered the problem that routers may not be saturated due to bandwidth, but due to packet rate? Maybe we should add a feature to change packetization interval? Joerg Ott agreed that this is something to consider, it's just another change in the media format. Magnus Westerlund asked if you can do other things than switch streams for congestion control? Philippe said yes, streams can be adapted in various ways, but this doesn't need protocol supoprt from RTSP. Ross Finlayson agreed that the concept was useful, but was unsure that RTSP is the place to put the signalling? Will the TCP nature of RTSP delay the congestion control signalling? Maybe use RTCP? Colin Perkins noted that it is important to differentiate between indication of loss for a stream (RTCP) and signalling to switch to a different stream (RTSP). Anders Klemets also liked the idea, but not the details. We have standard ways of specifying alternates in SDP, maybe want to leave those details out of this spec? Given the interest, it was agreed to move forward with this discussion on the mailing list. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 14 02:39:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25681 for ; Mon, 14 Apr 2003 02:39:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3E6kcf26661 for mmusic-archive@odin.ietf.org; Mon, 14 Apr 2003 02:46:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6kc826657 for ; Mon, 14 Apr 2003 02:46:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25678 for ; Mon, 14 Apr 2003 02:38:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xeP-0000Cc-00 for mmusic-web-archive@ietf.org; Mon, 14 Apr 2003 02:41:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 194xeP-0000CZ-00 for mmusic-web-archive@ietf.org; Mon, 14 Apr 2003 02:41:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6kB826649; Mon, 14 Apr 2003 02:46:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3E6jD826617 for ; Mon, 14 Apr 2003 02:45:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25649 for ; Mon, 14 Apr 2003 02:37:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 194xd3-0000CJ-00 for mmusic@ietf.org; Mon, 14 Apr 2003 02:39:45 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 194xd3-0000CG-00 for mmusic@ietf.org; Mon, 14 Apr 2003 02:39:45 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3E6dlRs004825; Mon, 14 Apr 2003 08:39:47 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id <2VAMDN2B>; Mon, 14 Apr 2003 08:39:48 +0200 Message-ID: <1F55F6582266314A85A55F6241509B670575B350@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: "'Colin Perkins'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Date: Mon, 14 Apr 2003 08:36:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > > > >> - Given the risks identified in the third paragraph of > >> section 5, it's not > >> clear to me why the entire SDP message doesn't need to be > >> authenticated? > > > >I have never understood why people don't apply security to > things :-) > >However, when it comes to SDP, the protection of the SDP will > >very much depend on the protocol carrying SDP and what security > >features are implemented (and defined as necessary). So it is out > >of the scope of this document to specify how to protect the SDP, > >and that is also why we only give a recommendation that you should > >apply some form of protection to the SDP. > > But if the SDP has to be transferred by a secure channel, > what is the point > of MIKEY? The SIP/SDP may only be protected hop-by-hop (i.e. between the SIP proxies and SIP proxy - terminal). MIKEY is then needed to provide end-to-end security for the media streams. More or less, you only need to trust the proxies to provide a reliable transport, but you do not need to trust the proxies for your media. An almost analogous example would be email. You may use SSL to your mail server (to secure your session and account), but if you like end-to-end protection, you do not rely on this but apply something like S/MIME... > > >> Are attacks possible by manipulating the non-authenticated > >> parts of the > >> SDP? > > > >If you, by attacks, are referring to attacks towards the key > management > >and the secured media, I would say no. > > But is may be possible to redirect a media stream, for example? Of course (note though that there are plenty of other methods to do re-direction attacks of streams if you happen to be "on-the-path"...). Fredrik > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 14 17:15:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22311 for ; Mon, 14 Apr 2003 17:15:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ELNbA25185 for mmusic-archive@odin.ietf.org; Mon, 14 Apr 2003 17:23:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELNb825182 for ; Mon, 14 Apr 2003 17:23:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22288 for ; Mon, 14 Apr 2003 17:15:18 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195BKo-0005LD-00 for mmusic-web-archive@ietf.org; Mon, 14 Apr 2003 17:17:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195BKn-0005L9-00 for mmusic-web-archive@ietf.org; Mon, 14 Apr 2003 17:17:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELNV825160; Mon, 14 Apr 2003 17:23:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ELLW825002 for ; Mon, 14 Apr 2003 17:21:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22174 for ; Mon, 14 Apr 2003 17:13:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195BIn-0005JW-00 for mmusic@ietf.org; Mon, 14 Apr 2003 17:15:45 -0400 Received: from nmh.informatik.uni-bremen.de ([134.102.224.3] ident=root) by ietf-mx with esmtp (Exim 4.12) id 195BIn-0005JR-00 for mmusic@ietf.org; Mon, 14 Apr 2003 17:15:45 -0400 Received: from tzi.uni-bremen.de (localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.12.9/8.10.1) with ESMTP id h3ELFYfB018212; Mon, 14 Apr 2003 23:15:34 +0200 (MEST) Message-ID: <3E9B24C9.3090800@tzi.uni-bremen.de> Date: Mon, 14 Apr 2003 23:14:49 +0200 From: Joerg Ott User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: mmusic@ietf.org CC: Colin Perkins , rkumar@cisco.com, fandreas@cisco.com References: <200304142041.h3EKf6OJ015678@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG Last Call on draft-rajeshkumar-mmusic-gpmd-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is to issue WGLC on draft-rajeshkumar-mmusic-gpmd-02.txt "SDP attribute for Qualifying Media Formats with Generic Parameters" for Proposed Standard. The WGLC is to expire on April, 30th, 2003. Please direct any technical comments to the list and the authors, and please send purely editorial remarks only to the authors. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 04:44:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19301 for ; Tue, 15 Apr 2003 04:44:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3F8qWD17007 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 04:52:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8qW817004 for ; Tue, 15 Apr 2003 04:52:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19295 for ; Tue, 15 Apr 2003 04:44:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195M5H-0000yS-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 04:46:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195M5G-0000yP-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 04:46:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8qP816996; Tue, 15 Apr 2003 04:52:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3F8pU816955 for ; Tue, 15 Apr 2003 04:51:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19281 for ; Tue, 15 Apr 2003 04:42:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195M4H-0000yE-00 for mmusic@ietf.org; Tue, 15 Apr 2003 04:45:29 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 195M4G-0000y5-00 for mmusic@ietf.org; Tue, 15 Apr 2003 04:45:28 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h3F8isC06026; Tue, 15 Apr 2003 08:44:54 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Apr 2003 04:46:02 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Fredrik Lindholm (EAB)'" , "'Colin Perkins'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Date: Tue, 15 Apr 2003 04:45:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , A few notes below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Fredrik Lindholm (EAB) [mailto:Fredrik.Lindholm@era.ericsson.se] > Sent: Sunday, April 13, 2003 11:37 PM > To: 'Colin Perkins' > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt > [snip] > > The SIP/SDP may only be protected hop-by-hop (i.e. between the > SIP proxies and SIP proxy - terminal). MIKEY is then needed to provide > end-to-end security for the media streams. More or less, you only > need to trust the proxies to provide a reliable transport, but > you do not need to trust the proxies for your media. > > An almost analogous example would be email. You may use SSL to your > mail server (to secure your session and account), but if you like > end-to-end protection, you do not rely on this but apply something > like S/MIME... > It is worth pointing out that SIP encourages support of S/MIME for just this reason. > > > > >> Are attacks possible by manipulating the non-authenticated parts of the > > >> SDP? > > > > > >If you, by attacks, are referring to attacks towards the key management > > >and the secured media, I would say no. > > > > But is may be possible to redirect a media stream, for example? > > Of course (note though that there are plenty of other methods to > do re-direction attacks of streams if you happen to be > "on-the-path"...). > Again, it is worth noting that wrapping SDP in S/MIME prevents this sort of attack (at least redirection at the layer of SDP - SIP, for example, has some other safeguards to prevent malicious redirection at the SIP layer). This of course speaks only to carrying SDP in SIP. But is it true that all of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME types, and consequently could use S/MIME if needed? > Fredrik > > > Colin > > > _______________________________________________ > 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 mailnull@www1.ietf.org Tue Apr 15 08:45:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25872 for ; Tue, 15 Apr 2003 08:45:24 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FCrXY00786 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 08:53:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCrW800783 for ; Tue, 15 Apr 2003 08:53:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25868 for ; Tue, 15 Apr 2003 08:44:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PqQ-0002OL-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 08:47:26 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195PqP-0002OI-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 08:47:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCrL800769; Tue, 15 Apr 2003 08:53:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FCqS800738 for ; Tue, 15 Apr 2003 08:52:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25829 for ; Tue, 15 Apr 2003 08:43:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195PpN-0002Nw-00 for mmusic@ietf.org; Tue, 15 Apr 2003 08:46:21 -0400 Received: from agh196.anlgh.org ([164.54.89.196] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 195PpN-0002Ns-00 for mmusic@ietf.org; Tue, 15 Apr 2003 08:46:21 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3FCjvCI003936; Tue, 15 Apr 2003 08:45:57 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304151245.h3FCjvCI003936@purple.nge.isi.edu> To: "Peterson, Jon" cc: "'Fredrik Lindholm (EAB)'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt In-Reply-To: Your message of "Tue, 15 Apr 2003 04:45:59 EDT." <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neustar.com> Date: Tue, 15 Apr 2003 07:45:57 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> "Peterson, Jon" writes: > >A few notes below. > >Jon Peterson >NeuStar, Inc. > >> -----Original Message----- >> From: Fredrik Lindholm (EAB) [mailto:Fredrik.Lindholm@era.ericsson.se] >> Sent: Sunday, April 13, 2003 11:37 PM >> To: 'Colin Perkins' >> Cc: mmusic@ietf.org >> Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt >> >[snip] >> >> The SIP/SDP may only be protected hop-by-hop (i.e. between the >> SIP proxies and SIP proxy - terminal). MIKEY is then needed to provide >> end-to-end security for the media streams. More or less, you only >> need to trust the proxies to provide a reliable transport, but >> you do not need to trust the proxies for your media. >> >> An almost analogous example would be email. You may use SSL to your >> mail server (to secure your session and account), but if you like >> end-to-end protection, you do not rely on this but apply something >> like S/MIME... >> > >It is worth pointing out that SIP encourages support of S/MIME for just this >reason. Although this requires you to trust any intermediate proxies. This need could perhaps be avoided if MIKEY authenticated the entire SDP end2end? >> > >> Are attacks possible by manipulating the non-authenticated parts >of the >> > >> SDP? >> > > >> > >If you, by attacks, are referring to attacks towards the key >management >> > >and the secured media, I would say no. >> > >> > But is may be possible to redirect a media stream, for example? >> >> Of course (note though that there are plenty of other methods to >> do re-direction attacks of streams if you happen to be >> "on-the-path"...). >> > >Again, it is worth noting that wrapping SDP in S/MIME prevents this sort of >attack (at least redirection at the layer of SDP - SIP, for example, has >some other safeguards to prevent malicious redirection at the SIP layer). > >This of course speaks only to carrying SDP in SIP. But is it true that all >of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME >types, and consequently could use S/MIME if needed? RTSP certainly could use S/MIME; SAP probably can't as it's unidirectional and one-to-many. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 10:26:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29343 for ; Tue, 15 Apr 2003 10:26:06 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FEYFE07426 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 10:34:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEYF807423 for ; Tue, 15 Apr 2003 10:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29327 for ; Tue, 15 Apr 2003 10:25:35 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RPq-0002mJ-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 10:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195RPp-0002mG-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 10:28:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEY6807413; Tue, 15 Apr 2003 10:34:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FEXl807380 for ; Tue, 15 Apr 2003 10:33:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29318 for ; Tue, 15 Apr 2003 10:25:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RPP-0002m6-00 for mmusic@ietf.org; Tue, 15 Apr 2003 10:27:39 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 195RPO-0002m3-00 for mmusic@ietf.org; Tue, 15 Apr 2003 10:27:38 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3FERjI3019551 for ; Tue, 15 Apr 2003 16:27:45 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 2VAM5PVK; Tue, 15 Apr 2003 16:27:46 +0200 Message-ID: <3E9C16E9.5000501@era.ericsson.se> Date: Tue, 15 Apr 2003 16:27:53 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP meeting agenda 16 april Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, There is a RTSP telecon tomorrow wednesday, the 16th April at 18.00 CET (GMT +2). I have sent out the meeting details to the RTSP logistics lists. IF you want to participate and haven't received the details send me a mail. Best Regards Magnus ----------------- Agenda 030416 1. Opening of meeting. 2. Since last meeting (5th of March). a. Bug513737 - Who will write it up? b. Bug 533691 & 513880 - Aravind to write up, progress? c. http://rtsp.org/bug556061 - Fix state machine to allow for REDIRECT at any time, including in INIT state. d. http://rtsp.org/bug556295 - Allow: needs explanation. e. Remove timed PLAY and PAUSE. With time I mean the specified usage of the time parameter in the Range header. f. Stream switching requirements document (Phillipe Gentric) g. Offer Answer for RTSP. Anybody willing to write requirements and use case? h. IANA registration comments? i. Ways to allow direct media destination to other than own IP address. (Phillipe Gentric) j. Multiple SSRC in RTSP. Redefine RTP-Info to solve issue? k. How to distinguish the updated specification. l. Warning header: For further discussion. m. RTSP servers behind NATs. Use case seems to exist. Requires someone to write scenario document. Decide on how to go forward compared with public network servers. Time line considerations. n. RTSP ALG for Linux netfilter. (Tom Marshall) 3. How to get things into the spec? 4. New Things a. Specification review. Plan to look through the latest draft and see what comments people has about it. b. http://rtsp.org/bug631148 better Info on RTSP proxies. c. http://rtsp.org/bug631957 Use of # and ? in RTSP URLs? d. http://rtsp.org/bug633148 Use of TCP and UDP. e. http://rtsp.org/bug633779 SET_PARAMETER responses. 5. Any other Issues 6. Next meeting 7. End meeting -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 11:05:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00698 for ; Tue, 15 Apr 2003 11:05:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FFDgn10866 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 11:13:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFDg810863 for ; Tue, 15 Apr 2003 11:13:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00673 for ; Tue, 15 Apr 2003 11:05:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195S20-0002yX-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 11:07:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195S20-0002yU-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 11:07:32 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFDa810853; Tue, 15 Apr 2003 11:13:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FF8p810644 for ; Tue, 15 Apr 2003 11:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00517 for ; Tue, 15 Apr 2003 11:00:11 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195RxK-0002wf-00 for mmusic@ietf.org; Tue, 15 Apr 2003 11:02:42 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 195RxJ-0002wX-00 for mmusic@ietf.org; Tue, 15 Apr 2003 11:02:42 -0400 Received: from dynamicsoft.com ([63.113.47.242]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3FF2IBd017763; Tue, 15 Apr 2003 11:02:19 -0400 (EDT) Message-ID: <3E9C1EF3.6030507@dynamicsoft.com> Date: Tue, 15 Apr 2003 11:02:11 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: "Peterson, Jon" , "'Fredrik Lindholm (EAB)'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt References: <200304151245.h3FCjvCI003936@purple.nge.isi.edu> In-Reply-To: <200304151245.h3FCjvCI003936@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Colin Perkins wrote: >>>An almost analogous example would be email. You may use SSL to your >>>mail server (to secure your session and account), but if you like >>>end-to-end protection, you do not rely on this but apply something >>>like S/MIME... >>> >> >>It is worth pointing out that SIP encourages support of S/MIME for just this >>reason. > > > Although this requires you to trust any intermediate proxies. This need > could perhaps be avoided if MIKEY authenticated the entire SDP end2end? I'm confused. S/MIME does not require you to trust intermediate proxies, thats the whole point. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 11:49:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02176 for ; Tue, 15 Apr 2003 11:49:00 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FFvCJ13905 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 11:57:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFvB813902 for ; Tue, 15 Apr 2003 11:57:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02128 for ; Tue, 15 Apr 2003 11:48:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Si5-0003DM-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 11:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195Si5-0003DJ-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 11:51:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFv9813888; Tue, 15 Apr 2003 11:57:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FFtl813727 for ; Tue, 15 Apr 2003 11:55:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02051 for ; Tue, 15 Apr 2003 11:47:05 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195Sgi-0003CI-00 for mmusic@ietf.org; Tue, 15 Apr 2003 11:49:36 -0400 Received: from demo73.anlgh.org ([164.54.92.73] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 195Sgi-0003C9-00 for mmusic@ietf.org; Tue, 15 Apr 2003 11:49:36 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3FFn5CI006736; Tue, 15 Apr 2003 11:49:05 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304151549.h3FFn5CI006736@purple.nge.isi.edu> To: Jonathan Rosenberg cc: "Peterson, Jon" , "'Fredrik Lindholm (EAB)'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt In-Reply-To: Your message of "Tue, 15 Apr 2003 11:02:11 EDT." <3E9C1EF3.6030507@dynamicsoft.com> Date: Tue, 15 Apr 2003 10:49:05 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> Jonathan Rosenberg writes: > > >Colin Perkins wrote: > >>>>An almost analogous example would be email. You may use SSL to your >>>>mail server (to secure your session and account), but if you like >>>>end-to-end protection, you do not rely on this but apply something >>>>like S/MIME... >>>> >>> >>>It is worth pointing out that SIP encourages support of S/MIME for just this >>>reason. >> >> >> Although this requires you to trust any intermediate proxies. This need >> could perhaps be avoided if MIKEY authenticated the entire SDP end2end? > >I'm confused. > >S/MIME does not require you to trust intermediate proxies, thats the >whole point. Duh, my bad. Confusing S/MIME and SSL. Ignore that message, not enough coffee this morning :) Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 14:25:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06173 for ; Tue, 15 Apr 2003 14:25:17 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FIXWC25466 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 14:33:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIXW825463 for ; Tue, 15 Apr 2003 14:33:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06117 for ; Tue, 15 Apr 2003 14:24:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195V9K-0003te-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 14:27:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195V9K-0003tb-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 14:27:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIXF825419; Tue, 15 Apr 2003 14:33:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FIWm825387 for ; Tue, 15 Apr 2003 14:32:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06089 for ; Tue, 15 Apr 2003 14:24:02 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195V8c-0003sy-00 for mmusic@ietf.org; Tue, 15 Apr 2003 14:26:34 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 195V8c-0003sv-00 for mmusic@ietf.org; Tue, 15 Apr 2003 14:26:34 -0400 Received: from cscoamera13263.cisco.com (rtp-vpn1-695.cisco.com [10.82.226.183]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3FIQ9B1009079; Tue, 15 Apr 2003 14:26:10 -0400 (EDT) Message-Id: <5.1.1.5.2.20030415111609.0bc8aed0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Tue, 15 Apr 2003 11:26:07 -0700 To: "Peterson, Jon" From: Mark Baugher Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Cc: mmusic@ietf.org In-Reply-To: <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neusta r.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Jon, At 04:45 AM 4/15/2003 -0400, Peterson, Jon wrote: <...> >This of course speaks only to carrying SDP in SIP. But is it true that all >of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME >types, and consequently could use S/MIME if needed? SAP is to a group so we won't get confidentiality but would get authentication. Mark > > Fredrik > > > > > Colin > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 15:25:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08902 for ; Tue, 15 Apr 2003 15:25:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FJXJO29780 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 15:33:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FJXJ829775 for ; Tue, 15 Apr 2003 15:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08887 for ; Tue, 15 Apr 2003 15:24:31 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195W59-0004Au-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 15:27:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195W59-0004Ar-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 15:27:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FJXC829766; Tue, 15 Apr 2003 15:33:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FJWR829740 for ; Tue, 15 Apr 2003 15:32:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08873 for ; Tue, 15 Apr 2003 15:23:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195W4K-0004Ad-00 for mmusic@ietf.org; Tue, 15 Apr 2003 15:26:12 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 195W4J-0004AY-00 for mmusic@ietf.org; Tue, 15 Apr 2003 15:26:11 -0400 Received: from stntimc1.va.neustar.com (stntimc1.va.neustar.com [10.31.13.11]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h3FJPhC21966; Tue, 15 Apr 2003 19:25:43 GMT Received: by stntimc1.va.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Apr 2003 15:26:51 -0400 Message-ID: <0449D80A0E9B614A83FA9031B07E8D3B2579BD@stntexch2.va.neustar.com> From: "Peterson, Jon" To: "'Mark Baugher'" Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt Date: Tue, 15 Apr 2003 15:26:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , [snip] > > SAP is to a group so we won't get confidentiality but would > get authentication. > I imagine that for redirection attacks targeting m= lines, and similar mischief, the properties we really want are authentication and integrity, which do seem achievable for SAP. Jon Peterson NeuStar, Inc. > Mark > > > > > Fredrik > > > > > > > Colin > > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 16:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10774 for ; Tue, 15 Apr 2003 16:33:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FKfS002686 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 16:41:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKfS802682 for ; Tue, 15 Apr 2003 16:41:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10758 for ; Tue, 15 Apr 2003 16:32:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195X96-0004RL-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:35:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195X95-0004RI-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:35:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKfB802671; Tue, 15 Apr 2003 16:41:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKeK802617 for ; Tue, 15 Apr 2003 16:40:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10696 for ; Tue, 15 Apr 2003 16:31:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195X80-0004Qq-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:34:04 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 195X6X-0004Pu-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:34:04 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3FKWQ13091924 for ; Tue, 15 Apr 2003 13:32:41 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3FKVB7b090448; Tue, 15 Apr 2003 13:31:11 -0700 (PDT) Message-Id: <4.3.1.1.20030415132203.00c43100@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 15 Apr 2003 13:26:49 -0700 To: mmusic@ietf.org From: Ross Finlayson Cc: bquinn@celoxnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Updated SDP "source filter" Internet Draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , FYI, I have just submitted an updated copy of the SDP "source filter" draft. You can also find a copy online at http://www.live.com/draft-mmusic-sdp-srcfilter-04.txt This version contains several formatting and 'I-D nit' improvements (thanks to feedback from Magnus Westerlund and Colin Perkins), and clarifies how source filters are applied to "c=" lines that specify multiple multicast addresses. Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 16:34:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10831 for ; Tue, 15 Apr 2003 16:34:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FKgHR02744 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 16:42:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKgH802741 for ; Tue, 15 Apr 2003 16:42:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10820 for ; Tue, 15 Apr 2003 16:33:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195X9s-0004Rc-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:36:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195X9s-0004RZ-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:36:00 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKg2802719; Tue, 15 Apr 2003 16:42:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKfU802699 for ; Tue, 15 Apr 2003 16:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10763 for ; Tue, 15 Apr 2003 16:32:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195X97-0004RQ-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:35:13 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 195X7t-0004Qm-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:35:13 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3FKY513093956 for ; Tue, 15 Apr 2003 13:34:05 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3FKWoPV092451; Tue, 15 Apr 2003 13:32:50 -0700 (PDT) Message-Id: <4.3.1.1.20030415132203.00c43100@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 15 Apr 2003 13:26:49 -0700 To: mmusic@ietf.org From: Ross Finlayson Cc: bquinn@celoxnetworks.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Updated SDP "source filter" Internet Draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , FYI, I have just submitted an updated copy of the SDP "source filter" draft. You can also find a copy online at http://www.live.com/draft-mmusic-sdp-srcfilter-04.txt This version contains several formatting and 'I-D nit' improvements (thanks to feedback from Magnus Westerlund and Colin Perkins), and clarifies how source filters are applied to "c=" lines that specify multiple multicast addresses. Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 15 16:51:57 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11497 for ; Tue, 15 Apr 2003 16:51:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3FL0DO03946 for mmusic-archive@odin.ietf.org; Tue, 15 Apr 2003 17:00:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FL0D803940 for ; Tue, 15 Apr 2003 17:00:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11366 for ; Tue, 15 Apr 2003 16:51:25 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195XRE-0004Z8-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:53:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195XRD-0004Z5-00 for mmusic-web-archive@ietf.org; Tue, 15 Apr 2003 16:53:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FL04803767; Tue, 15 Apr 2003 17:00:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3FKxN803606 for ; Tue, 15 Apr 2003 16:59:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11257 for ; Tue, 15 Apr 2003 16:50:36 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195XQQ-0004XI-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:53:06 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 195XQQ-0004X2-00 for mmusic@ietf.org; Tue, 15 Apr 2003 16:53:06 -0400 Received: from cisco.com (sjc-vpn1-460.cisco.com [10.21.97.204]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3FKqOgE007826; Tue, 15 Apr 2003 13:52:40 -0700 (PDT) Message-ID: <3E9C7106.568AEA3B@cisco.com> Date: Tue, 15 Apr 2003 16:52:23 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Fredrik Lindholm (EAB)'" , "'Colin Perkins'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt References: <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > This of course speaks only to carrying SDP in SIP. But is it true that all > of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME > types, and consequently could use S/MIME if needed? > Megaco (and MGCP) don't -- Flemming > > > Fredrik > > > > > Colin > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 16 10:28:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03436 for ; Wed, 16 Apr 2003 10:28:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GEaua25178 for mmusic-archive@odin.ietf.org; Wed, 16 Apr 2003 10:36:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEau825175 for ; Wed, 16 Apr 2003 10:36:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03412 for ; Wed, 16 Apr 2003 10:27:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195nvU-0001pc-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 10:30:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195nvU-0001pY-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 10:30:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEaK825141; Wed, 16 Apr 2003 10:36:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEZG825097 for ; Wed, 16 Apr 2003 10:35:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03344 for ; Wed, 16 Apr 2003 10:26:06 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195ntt-0001oz-00 for mmusic@ietf.org; Wed, 16 Apr 2003 10:28:37 -0400 Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx with esmtp (Exim 4.12) id 195nts-0001ol-00 for mmusic@ietf.org; Wed, 16 Apr 2003 10:28:36 -0400 Received: from zcard307.ca.nortel.com (zcard307.ca.nortel.com [47.129.242.67]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h3GERam16463; Wed, 16 Apr 2003 10:27:36 -0400 (EDT) Received: from zcard0kc.ca.nortel.com ([47.129.242.164]) by zcard307.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GDF11QHF; Wed, 16 Apr 2003 10:27:36 -0400 Received: from nortelnetworks.com (acart1e3.ca.nortel.com [47.129.129.112]) by zcard0kc.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2WPXXPNP; Wed, 16 Apr 2003 10:27:36 -0400 Message-ID: <3E9D6856.3040008@nortelnetworks.com> Date: Wed, 16 Apr 2003 10:27:34 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-ca, en-us, en, fr MIME-Version: 1.0 To: Flemming Andreasen CC: "Peterson, Jon" , "'Fredrik Lindholm (EAB)'" , "'Colin Perkins'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt References: <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neustar.com> <3E9C7106.568AEA3B@cisco.com> In-Reply-To: <3E9C7106.568AEA3B@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The other point about these protocols is that they are not intended to be handled by intermediate proxies. Flemming Andreasen wrote: > > "Peterson, Jon" wrote: > > > > > >>This of course speaks only to carrying SDP in SIP. But is it true that all >>of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME >>types, and consequently could use S/MIME if needed? >> > > > Megaco (and MGCP) don't > > -- Flemming > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 16 10:44:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04157 for ; Wed, 16 Apr 2003 10:44:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GErE826948 for mmusic-archive@odin.ietf.org; Wed, 16 Apr 2003 10:53:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GErE826945 for ; Wed, 16 Apr 2003 10:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04109 for ; Wed, 16 Apr 2003 10:44:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195oBG-0001ve-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 10:46:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195oBG-0001vb-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 10:46:34 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEr9826924; Wed, 16 Apr 2003 10:53:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GEoN826741 for ; Wed, 16 Apr 2003 10:50:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04046 for ; Wed, 16 Apr 2003 10:41:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195o8V-0001ud-00 for mmusic@ietf.org; Wed, 16 Apr 2003 10:43:44 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 195o8V-0001uJ-00 for mmusic@ietf.org; Wed, 16 Apr 2003 10:43:43 -0400 Received: from cisco.com (sjc-vpn1-118.cisco.com [10.21.96.118]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3GEh6mi026660; Wed, 16 Apr 2003 07:43:07 -0700 (PDT) Message-ID: <3E9D6BFA.7F472D3E@cisco.com> Date: Wed, 16 Apr 2003 10:43:06 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom Taylor CC: "Peterson, Jon" , "'Fredrik Lindholm (EAB)'" , "'Colin Perkins'" , mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-kmgmt-ext-07.txt References: <0449D80A0E9B614A83FA9031B07E8D3B2579B9@stntexch2.va.neustar.com> <3E9C7106.568AEA3B@cisco.com> <3E9D6856.3040008@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Taylor wrote: > The other point about these protocols is that they are not intended to be handled by > intermediate proxies. > This is true, an although I agree than an MG needs to place some amount of trust in its MGC, not everybody want to place 100% trust in their MGC. For example, some MGs may want to negotiate media stream ciphers (or at least keys) in such a way that their MGC will not be able to decipher the media stream. -- Flemming > > Flemming Andreasen wrote: > > > > "Peterson, Jon" wrote: > > > > > > > > > > > >>This of course speaks only to carrying SDP in SIP. But is it true that all > >>of the protocols that currently use SDP (RTSP, SAP, SIP...) carry MIME > >>types, and consequently could use S/MIME if needed? > >> > > > > > > Megaco (and MGCP) don't > > > > -- Flemming > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 16 12:01:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06794 for ; Wed, 16 Apr 2003 12:01:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3GG9fl01362 for mmusic-archive@odin.ietf.org; Wed, 16 Apr 2003 12:09:41 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GG9f801359 for ; Wed, 16 Apr 2003 12:09:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06736 for ; Wed, 16 Apr 2003 12:00:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195pNE-0002Nj-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 12:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 195pND-0002Ng-00 for mmusic-web-archive@ietf.org; Wed, 16 Apr 2003 12:02:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GG9b801315; Wed, 16 Apr 2003 12:09:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3GG2s832392 for ; Wed, 16 Apr 2003 12:02:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06503 for ; Wed, 16 Apr 2003 11:53:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 195pGf-0002LA-00 for mmusic@ietf.org; Wed, 16 Apr 2003 11:56:13 -0400 Received: from kathmandu.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 195pGe-0002L7-00 for mmusic@ietf.org; Wed, 16 Apr 2003 11:56:12 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA14302 for ; Wed, 16 Apr 2003 09:56:21 -0600 (MDT) Received: from sun.com (vpn-129-150-16-90.SFBay.Sun.COM [129.150.16.90]) by phys-ha2mpka.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA27047 for ; Wed, 16 Apr 2003 08:56:20 -0700 (PDT) Message-ID: <3E9D7CE9.1010004@sun.com> Date: Wed, 16 Apr 2003 11:55:21 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: multipart/alternative; boundary="------------040401060004040602080805" Subject: [MMUSIC] Backwards range and negative scale clarification (bugs 533691, 513880) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --------------040401060004040602080805 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Folks, In my attempt to clarify the negative scale and backwards range issues brought up by bugs http://rtsp.org/bug533691 & http://rtsp.org/bug513880 some issues surfaced with regards to the current definition of ranges in the spec. I wanted to discuss these issues before sending off my write up. Issue 1: --------- Range is defined in RTSP as a half open interval. To quote from draft-03 Ranges are half-open intervals, including the lower point, but excluding the upper point. In other words, a range of a-b starts exactly at time a, but stops just before b. Now the resolution that we came up with for this issue was that we would always go from the first number in the range to the last number in the range. So for example, if the range of a PLAY request was Range: npt=10-15 we would go from 10 -> 15, where the play would stop just before 15. If the request had range and scale headers as the following: Scale: -1 Range: npt=15-10 the play would go backwards and we would go from 15 -> 10. Now the question is how do we interpret the half-open rule. I.e. Do we stop at 10 or just before we reach 10 (i.e. npt > 10) in the backwards scenario above? The latter seems like they way to interpret the half - open rule. But if we interpret it that way, then how do we deal with the following: Scale: -1 Range: npt=15-0 We would have to stop before 0 and there would be no way to get to 0 since you cannot specify negative ranges. Obviously the way to get around this is to do the following: Scale: -1 Range: npt=15- But this doesn't seem too clean to me. The other option is to say that backwards ranges are always closed ranges. This, however, makes ranges a bit more inconsisted and harder to deal with. Issue 2: ---------- The other thing that doesn't make sense with backwards ranges are the Clock ranges. For example: Scale: -1 Range: clock=20030416T000000.00Z-20030101T000000.00Z makes no sense because clocks cant go backwards. So I propose that Scale can only be negative for ranges that deal with relative time rather than absolute time. --------------040401060004040602080805 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Folks,    
In my attempt to clarify the negative scale and backwards range issues brought up by bugs http://rtsp.org/bug533691 &  http://rtsp.org/bug513880 some issues surfaced with regards to the current definition of ranges in the spec.  I wanted to discuss these issues before sending off my write up.

Issue 1:
---------
Range is defined in RTSP as a half open interval.  To quote from draft-03
Ranges are half-open intervals, including the lower point, but
excluding the upper point. In other words, a range of a-b starts
exactly at time a, but stops just before b.
Now the resolution that we came up with for this issue was that we would always go from the first number in the range to the last number in the range.  So for example, if the range of a PLAY request was
    Range: npt=10-15
we would go from 10 -> 15, where the play would stop just before 15.  If the request had  range and scale headers as the following:
    Scale: -1
    Range: npt=15-10
the play would go backwards and we would go from 15 -> 10.

Now the question is how do we interpret the half-open rule.  I.e.  Do we stop at 10 or just before we reach 10 (i.e. npt > 10) in the backwards scenario above? The latter seems like they way to interpret the half - open rule.  But if we interpret it that way, then how do we deal with the following:
    Scale: -1
    Range: npt=15-0
We would have to stop before 0 and there would be no way to get to 0 since you cannot specify negative ranges.  Obviously the way to get around this is to do the following:
    Scale: -1
    Range: npt=15-
But this doesn't seem too clean to me.

The other option is to say that  backwards ranges are always closed ranges.  This, however, makes ranges a bit more inconsisted and harder to deal with.

Issue 2:
----------
The other thing that doesn't make sense with backwards ranges are the Clock ranges.  For example:
    Scale: -1
    Range: clock=20030416T000000.00Z-20030101T000000.00Z
makes no sense because clocks cant go backwards.

So I propose that Scale can only be negative for ranges that deal with relative time rather than absolute time.


--------------040401060004040602080805-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 17 07:38:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16431 for ; Thu, 17 Apr 2003 07:38:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HBlJY27488 for mmusic-archive@odin.ietf.org; Thu, 17 Apr 2003 07:47:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBlJ827485 for ; Thu, 17 Apr 2003 07:47:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16399 for ; Thu, 17 Apr 2003 07:37:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 1967kT-0006lg-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 07:40:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1967kS-0006ld-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 07:40:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBlF827471; Thu, 17 Apr 2003 07:47:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HBZn826192 for ; Thu, 17 Apr 2003 07:35:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15811; Thu, 17 Apr 2003 07:26:14 -0400 (EDT) Message-Id: <200304171126.HAA15811@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 17 Apr 2003 07:26:14 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-srcfilter-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol (SDP) Source Filters Author(s) : B. Quinn, R. Finlayson Filename : draft-ietf-mmusic-sdp-srcfilter-04.txt Pages : 10 Date : 2003-4-16 This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. In particular, an inclusive source-filter can be used to specify a Source-Specific Multicast (SSM) session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-srcfilter-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-srcfilter-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-16135654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-srcfilter-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-srcfilter-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-16135654.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 17 18:05:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10464 for ; Thu, 17 Apr 2003 18:05:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMF2613904 for mmusic-archive@odin.ietf.org; Thu, 17 Apr 2003 18:15:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMF2813901 for ; Thu, 17 Apr 2003 18:15:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10394 for ; Thu, 17 Apr 2003 18:05:13 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HXh-00038L-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 18:07:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HXg-00038H-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 18:07:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMEv813876; Thu, 17 Apr 2003 18:14:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMBb813692 for ; Thu, 17 Apr 2003 18:11:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10095 for ; Thu, 17 Apr 2003 18:01:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HUN-00036c-00 for mmusic@ietf.org; Thu, 17 Apr 2003 18:04:15 -0400 Received: from tik6.ethz.ch ([129.132.119.136]) by ietf-mx with esmtp (Exim 4.12) id 196HUN-00036Y-00 for mmusic@ietf.org; Thu, 17 Apr 2003 18:04:15 -0400 Received: from localhost (localhost [127.0.0.1]) by tik6.ethz.ch (Postfix) with ESMTP id 6BDD66ADD7 for ; Fri, 18 Apr 2003 00:04:28 +0200 (MEST) Received: from ceid.upatras.gr (dhcp-17-061.via-eth.ch [192.33.101.61]) by tik6.ethz.ch (Postfix) with ESMTP id 26ACA6ADBB for ; Fri, 18 Apr 2003 00:04:28 +0200 (MEST) Message-ID: <3E9F2421.4000606@ceid.upatras.gr> Date: Fri, 18 Apr 2003 00:01:05 +0200 From: Kostas Katrinis Reply-To: katrinis@ceid.upatras.gr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 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-Virus-Scanned: by AMaViS new-20020517 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-levin-sipping-conferencing-requirements-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, although the draft-levin-sipping-conferencing-requirements-03.txt expired last March, I wanted to ask some guideline questions on this: - according to the functionality offered by SIP as mentioned in RFC 3261, SIP is responsible for creation/termination and management of sessions. As such, is it in the scope of SIP (or of services implemented via SIP messages) to facilitate also conference control? As an example,in draft-levin-sipping-conferencing-requirements-03.txt the following functionality is posed as a required service(citing the draft): " REQ -2: Given a conference identifier, a means MUST be defined for a user agent to remove a participant from the conference." Given that participant 1 (that is authorized to remove a participant) does not have the dialog information in order to remove participant 2 from the conference, participant 1 should first signal the conference server the command to remove participant 2 from the conference and then the conference focus should take over the removal of participant 2. Now, should the instruction from the removal issued from the participant 1 to the focus be implemented with SIP means or with another proprietary protocol? - regarding the conference policy control protocol, is there any provision to standardize it? Will it be implemented in SIP scope (additional SIP messages) or by defining a new protocol? Thank you in advance, Kostas Katrinis _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 17 20:50:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15452 for ; Thu, 17 Apr 2003 20:50:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I107Z24087 for mmusic-archive@odin.ietf.org; Thu, 17 Apr 2003 21:00:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I106824084 for ; Thu, 17 Apr 2003 21:00:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15441 for ; Thu, 17 Apr 2003 20:50:15 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196K7N-0003ro-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 20:52:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196K7N-0003rl-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 20:52:41 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I101824062; Thu, 17 Apr 2003 21:00:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I0vA823946 for ; Thu, 17 Apr 2003 20:57:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15353 for ; Thu, 17 Apr 2003 20:47:19 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196K4X-0003qf-00 for mmusic@ietf.org; Thu, 17 Apr 2003 20:49:45 -0400 Received: from tog-wakko3.prognet.com ([207.188.29.248] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 196K4X-0003qc-00 for mmusic@ietf.org; Thu, 17 Apr 2003 20:49:45 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 196K4l-0000Zd-00 for ; Thu, 17 Apr 2003 17:49:59 -0700 Date: Thu, 17 Apr 2003 17:49:59 -0700 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030418004958.GC2063@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] What is "current"? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Here's an interesting issue. RFC2326 says this: Since many of the definitions and syntax are identical to HTTP/1.1, =20 this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]). "current" can be taken two ways: current as of the writing, or current as of the reading. Further, it seems the meaning of an empty "Accept-Encoding:" header has been reversed between 2068 and 2616. The former says explicitly that it means none are acceptable and the latter says that the "identity" encoding is always acceptable unless explicitly refused. It seems that there is a bug in the HTTP spec and this makes it a bug in the RTSP spec. What is a well-behaved server to do in this case??? --=20 A revised schedule is to business what a new season is to an athlete or a new canvas to an artist. -- Norman Augustine --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+n0u2qznSmcYu2m8RArRTAJ0REZLX4oScXIwSLPFyy808sHGh1gCZATO/ vWRoUOB53KuvSLSZfLuv1LM= =lTV9 -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 17 23:34:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18299 for ; Thu, 17 Apr 2003 23:34:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I3iFH01898 for mmusic-archive@odin.ietf.org; Thu, 17 Apr 2003 23:44:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I3iF801895 for ; Thu, 17 Apr 2003 23:44:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18288 for ; Thu, 17 Apr 2003 23:34:20 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196MgB-0004SB-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 23:36:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196MgA-0004S8-00 for mmusic-web-archive@ietf.org; Thu, 17 Apr 2003 23:36:46 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I3i3801886; Thu, 17 Apr 2003 23:44:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I3fP801841 for ; Thu, 17 Apr 2003 23:41:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18237 for ; Thu, 17 Apr 2003 23:31:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196MdR-0004Rx-00 for mmusic@ietf.org; Thu, 17 Apr 2003 23:33:57 -0400 Received: from bullwinkle.real.com ([207.188.22.30] helo=wullbinkle.real.com) by ietf-mx with esmtp (Exim 4.12) id 196MdQ-0004Ru-00 for mmusic@ietf.org; Thu, 17 Apr 2003 23:33:56 -0400 Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2-glompatched-x2/8.12.2) with ESMTP id h3I3XbNF002503 for ; Thu, 17 Apr 2003 20:33:37 -0700 Received: from raven.dev.prognet.com ([172.22.22.16]) by real.com (8.12.2-glompatched-x2/8.12.2) with ESMTP id h3I3XaU4022739; Thu, 17 Apr 2003 20:33:37 -0700 Date: Thu, 17 Apr 2003 20:36:26 -0700 (PDT) From: Aaron Colwell To: Tom Marshall cc: mmusic@ietf.org Subject: Re: [MMUSIC] What is "current"? In-Reply-To: <20030418004958.GC2063@real.com> Message-ID: References: <20030418004958.GC2063@real.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Looks like you are our server guy looking into this bug. :) Here is my interpretation of the HTTP spec. In RFC 2068 it says "An empty Accept-Encoding value indicates none are acceptable". I interpret that to mean that none of the encoding types (ie. compress or gzip) are acceptable. Since not specifying the Accept-Encoding field means that the server can choose any encoding it wants, sending the header with an empty value seems to me to be the only way to tell the server you don't want it to use any encoding. I think that RFC 2616 tries to clarify this condition, but makes things a little confusing by introducing the "identity" encoding. RFC 2616 says "If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable." If you use my interpretation of RFC 2068, then the 2 RFCs are consistent. If my interpretation is wrong then I agree with you that they are inconsistent. Aaron On Thu, 17 Apr 2003, Tom Marshall wrote: > Here's an interesting issue. RFC2326 says this: > > Since many of the definitions and syntax are identical to HTTP/1.1, > this specification only points to the section where they are defined > rather than copying it. For brevity, [HX.Y] is to be taken to refer > to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]). > > "current" can be taken two ways: current as of the writing, or current as of > the reading. > > Further, it seems the meaning of an empty "Accept-Encoding:" header has been > reversed between 2068 and 2616. The former says explicitly that it means > none are acceptable and the latter says that the "identity" encoding is > always acceptable unless explicitly refused. > > It seems that there is a bug in the HTTP spec and this makes it a bug in the > RTSP spec. > > What is a well-behaved server to do in this case??? > > -- > A revised schedule is to business what a new season is to an athlete or a > new canvas to an artist. > -- Norman Augustine > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 18 00:59:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19993 for ; Fri, 18 Apr 2003 00:59:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I58S306839 for mmusic-archive@odin.ietf.org; Fri, 18 Apr 2003 01:08:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I58S806836 for ; Fri, 18 Apr 2003 01:08:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19966 for ; Fri, 18 Apr 2003 00:58:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Nze-0004kV-00 for mmusic-web-archive@ietf.org; Fri, 18 Apr 2003 01:00:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Nzd-0004kS-00 for mmusic-web-archive@ietf.org; Fri, 18 Apr 2003 01:00:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I57t806820; Fri, 18 Apr 2003 01:07:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I55Z805908 for ; Fri, 18 Apr 2003 01:05:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19850 for ; Fri, 18 Apr 2003 00:55:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Nwr-0004jU-00 for mmusic@ietf.org; Fri, 18 Apr 2003 00:58:05 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 196Nwr-0004jQ-00 for mmusic@ietf.org; Fri, 18 Apr 2003 00:58:05 -0400 Received: from dynamicsoft.com ([63.113.46.20]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3I4ncBd019072; Fri, 18 Apr 2003 00:49:40 -0400 (EDT) Message-ID: <3E9F83DE.5060202@dynamicsoft.com> Date: Fri, 18 Apr 2003 00:49:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: katrinis@ceid.upatras.gr CC: mmusic@ietf.org Subject: Re: [MMUSIC] Comments on draft-levin-sipping-conferencing-requirements-03.txt References: <3E9F2421.4000606@ceid.upatras.gr> In-Reply-To: <3E9F2421.4000606@ceid.upatras.gr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Kostas Katrinis wrote: > Dear all, > > although the draft-levin-sipping-conferencing-requirements-03.txt > expired last March, I wanted to ask some guideline questions on this: > > - according to the functionality offered by SIP as mentioned in RFC > 3261, SIP is responsible for creation/termination and management of > sessions. As such, is it in the scope of SIP (or of services implemented > via SIP messages) to facilitate also conference control? No. > As an example,in > draft-levin-sipping-conferencing-requirements-03.txt the following > functionality is posed as a required service(citing the draft): > " REQ -2: Given a conference identifier, a means MUST be defined for a > user agent to remove a participant from the conference." > > Given that participant 1 (that is authorized to remove a participant) > does not have the dialog information in order to remove participant 2 > from the conference, participant 1 should first signal the conference > server the command to remove participant 2 from the conference and then > the conference focus should take over the removal of participant 2. > Now, should the instruction from the removal issued from the participant > 1 to the focus be implemented with SIP means or with another > proprietary protocol? A different protocol will be used for conference control. The conferencing design team in sipping is working on it. There is no proposed protocol right now, though SOAP is a likely candidate. We do have requirements for this protocol however: http://www.ietf.org/internet-drafts/draft-koskelainen-sipping-conf-policy-req-00.txt -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 18 14:51:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22383 for ; Fri, 18 Apr 2003 14:51:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IJ1V505395 for mmusic-archive@odin.ietf.org; Fri, 18 Apr 2003 15:01:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJ1V805392 for ; Fri, 18 Apr 2003 15:01:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22379 for ; Fri, 18 Apr 2003 14:51:18 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196azX-0000xq-00 for mmusic-web-archive@ietf.org; Fri, 18 Apr 2003 14:53:43 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196azX-0000xn-00 for mmusic-web-archive@ietf.org; Fri, 18 Apr 2003 14:53:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IJ1K805350; Fri, 18 Apr 2003 15:01:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IIw1805158 for ; Fri, 18 Apr 2003 14:58:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22232 for ; Fri, 18 Apr 2003 14:47:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196aw9-0000vL-00 for mmusic@ietf.org; Fri, 18 Apr 2003 14:50:13 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 196aw9-0000uY-00 for mmusic@ietf.org; Fri, 18 Apr 2003 14:50:13 -0400 Received: from [172.23.111.21] ([::ffff:172.23.111.21]) (AUTH: LOGIN robla, ) by goodfellas.real.com with esmtp; Fri, 18 Apr 2003 11:49:51 -0700 From: Rob Lanphier To: mmusic@ietf.org Message-Id: <1050691814.2462.43.camel@dhcppc4> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 18 Apr 2003 11:50:14 -0700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Minutes for RTSP telecon April 16 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, Below are the minutes from the last RTSP conf call. They are also online here: http://rtsp.org/telecon/ Rob --- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com = Attendees = * Magnus Westerlund * Rob Lanphier * Aravind Narasimhan * Sean Sheedy * Andrea Basso * Thomas Zeng * Anders Klemets = Bug discussion = == Bug 513737 == * http://rtsp.org/bug513737 * Magnus: Who will write it up? * Aravind: if I get time * Aravind: in RTSP, range is defined as half-open interval * Aravind: with negative ranges, there's no way to get to zero * Magnus: is this really a problem? * Thomas: most video file have a frame at time=0 * Magnus: we could define a corner case for 0. I.e. the range would stay a half-open interval with the first number closed and the last number open, except in the case of 0. * Aravind: What about reversing the half-open interval * Rob: I like this * Andrea: what about I-frames * Thomas: it works the same as forwards * Andrea: it seems that consistency is more expressive * Aravind: now there's no way to start at a given time. Also the range header becomes harder to deal with because which interval is open depends on the Scale header. * Sean: define range to always mean that smallest range that is possible. * Thomas: changes existing implementations * Magnus: I'm don't think it does * Thomas: I'm still concerned * Magnus: we need a writeup * Sean: we could make range closed on both ends, rather than having it as half open. this definition change probably won't change current implementations (at least, not by enough to break things). * Thomas: why is 2326 the way it is * Rob: thought was about stringing together multiple ranges * conclusion: need more discussion on email == Bug 533691 and Bug 513880 == * http://rtsp.org/bug533691 & http://rtsp.org/bug513880 * Aravind to write up, progress? * Magnus: need more discussion on email == Issue #2 in Aravind's email == * See [http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01388.html Aravind's email] * Magnus: it is ok to have backwards clock ranges because you may have film index by clock ranges and you may want to go backwards in time. * Aravind: It seems to me that clock ranges refer to absolute time and that they shouldn't be allowed to go backwards. * magnus: Don't see a problem with clock ranges going backwards. == Bug 556061 == * http://rtsp.org/bug556061 * Fix state machine to allow for REDIRECT at any time, including in INIT state. * Magnus: needs writeup == Bug 556295 == * http://rtsp.org/bug556295 * Client issues PAUSE while server ready * Allow: needs explanation. * Magnus: been discussed...needs writeup * Thomas: I can write this up == Remove timed PLAY and PAUSE? == * Discussed at San Francisco IETF * Proposal: Remove timed PLAY and PAUSE. * Magnus: With time I mean the specified usage of the time parameter in the Range header. == Stream switching requirements document (Phillipe Gentric) == * Waiting for writeup == Offer Answer for RTSP == * Anybody willing to write requirements and use case? * Rob: no one really wanted to commit to this * Thomas: Phillipe may be interested * Andrea: May also be interested * Andrea will check into thsi == IANA registration comments? == * Magnus: send comments to the list == Ways to allow direct media destination to other than own IP address == * Magnus: Phillipe Gentric volunteered to look into this == Multiple SSRC in RTSP == * Magnus: Redefine RTP-Info to solve issue? * Thomas: this is because of stream switching * Magnus: no, relaying different sources * Magnus: e.g. relaying MBONE sessions * Thomas: our server mixes * Aravind: what about multiple participants? * Thomas: those should be different streams * Rob: that's inconsisent with standard use of RTP * Rob: we can solve this for the single SSRC case in RTP-Info, and then * Aravind: are we requiring SSRC in RTP-Info now? * Magnus: no...just explaining the limitation * Aravind: what about SSRC collision resolution? * Thomas: doesn't need to involve RTSP * Magnus: client is responsible for resolving * Rob: RTP-Info should be honored as initialization info only...RTCP takes over after that * Magnus: problem is when server is invited to existing RTP session * Thomas: can't really think about this problem without someone who's done it * Magnus: need more discussion * Thomas: I think Rob's proposal is sound * Aravind: what happens when client requests SSRC? * Magnus: comparing 2326 to current version. Non-normative suggestion to use SSRC from client. * Thomas: current 2326bis SSRC request is for unicast only * Aravind: multicast source gateway to unicast, the client may request SSRC...how does server honor? * Magnus: need to whether reconsider SSRC requests are useful or even valid * Aravind will write up == How to distinguish the updated specification == * Magnus: Need to consider bumping current version number to RTSP/1.1 * Thomas: we should increase version number * Magnus: if we work quickly, we can pull this off * Thomas: I can write this up == Next meeting == * Monday, April 28, at 9am PDT (GMT-7)/18:00 CMT (GMT+2) == Postponed items == * Bugs * Warning header: For further discussion. * RTSP servers behind NATs. Use case seems to exist. Requires someone to write scenario document. Decide on how to go forward compared with public network servers. Time line considerations. * RTSP ALG for Linux netfilter. (Tom Marshall) * How to get things into the spec? * New Things * Specification review. Plan to look through the latest draft and see what comments people has about it. * http://rtsp.org/bug631148 better Info on RTSP proxies. * http://rtsp.org/bug631957 Use of # and ? in RTSP URLs? * http://rtsp.org/bug633148 Use of TCP and UDP. * http://rtsp.org/bug633779 SET_PARAMETER responses. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sat Apr 19 03:58:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20303 for ; Sat, 19 Apr 2003 03:58:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3J888j28151 for mmusic-archive@odin.ietf.org; Sat, 19 Apr 2003 04:08:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3J888828148 for ; Sat, 19 Apr 2003 04:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20298 for ; Sat, 19 Apr 2003 03:57:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196nGV-0003eb-00 for mmusic-web-archive@ietf.org; Sat, 19 Apr 2003 04:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196nGV-0003eX-00 for mmusic-web-archive@ietf.org; Sat, 19 Apr 2003 04:00:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3J883828136; Sat, 19 Apr 2003 04:08:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HHQp823824 for ; Thu, 17 Apr 2003 13:26:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29173 for ; Thu, 17 Apr 2003 13:17:10 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196D2u-0001T6-00 for mmusic@ietf.org; Thu, 17 Apr 2003 13:19:36 -0400 Received: from tik6.ethz.ch ([129.132.119.136]) by ietf-mx with esmtp (Exim 4.12) id 196D2u-0001T3-00 for mmusic@ietf.org; Thu, 17 Apr 2003 13:19:36 -0400 Received: from localhost (localhost [127.0.0.1]) by tik6.ethz.ch (Postfix) with ESMTP id 1939B6ADD9 for ; Thu, 17 Apr 2003 19:19:49 +0200 (MEST) Received: from tik.ee.ethz.ch (dhcp-17-042.via-eth.ch [192.33.101.42]) by tik6.ethz.ch (Postfix) with ESMTP id C35676ADD8 for ; Thu, 17 Apr 2003 19:19:48 +0200 (MEST) Message-ID: <3E9EE16B.1080000@tik.ee.ethz.ch> Date: Thu, 17 Apr 2003 19:16:27 +0200 From: Kostas Katrinis Reply-To: katrinis@tik.ee.ethz.ch Organization: TIK - ETH Zurich User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS new-20020517 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Comments on draft-levin-sipping-conferencing-requirements-03.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, although the draft-levin-sipping-conferencing-requirements-03.txt expired last March, I wanted to ask some guideline questions on this: - according to the functionality offered by SIP as mentioned in RFC 3261, SIP is responsible for creation/termination and management of sessions. As such, is it in the scope of SIP (or of services implemented via SIP messages) to facilitate also conference control? As an example,in draft-levin-sipping-conferencing-requirements-03.txt the following functionality is posed as a required service(citing the draft): " REQ -2: Given a conference identifier, a means MUST be defined for a user agent to remove a participant from the conference." Given that participant 1 (that is authorized to remove a participant) does not have the dialog information in order to remove participant 2 from the conference, participant 1 should first signal the conference server the command to remove participant 2 from the conference and then the conference focus should take over the removal of participant 2. Now, should the instruction from the removal issued from the participant 1 to the focus be implemented with SIP means or with another proprietary protocol? - regarding the conference policy control protocol, is there any provision to standardize it? Will it be implemented in SIP scope (additional SIP messages) or by defining a new protocol? Thank you in advance, Kostas Katrinis _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Sat Apr 19 04:00:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20351 for ; Sat, 19 Apr 2003 04:00:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3J8A2O28234 for mmusic-archive@odin.ietf.org; Sat, 19 Apr 2003 04:10:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3J8A2828231 for ; Sat, 19 Apr 2003 04:10:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20324 for ; Sat, 19 Apr 2003 03:59:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196nIM-0003eu-00 for mmusic-web-archive@ietf.org; Sat, 19 Apr 2003 04:01:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196nIL-0003er-00 for mmusic-web-archive@ietf.org; Sat, 19 Apr 2003 04:01:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3J89w828200; Sat, 19 Apr 2003 04:09:58 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IAqx805851 for ; Fri, 18 Apr 2003 06:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07864; Fri, 18 Apr 2003 06:42:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196TMw-0006Kb-00; Fri, 18 Apr 2003 06:45:22 -0400 Received: from soleil.uvsq.fr ([193.51.24.1] ident=root) by ietf-mx with esmtp (Exim 4.12) id 196TMv-0006KY-00; Fri, 18 Apr 2003 06:45:21 -0400 Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.12.8p1/jtpda-5.4) with ESMTP id h3IAd09Y099065 ; Fri, 18 Apr 2003 12:39:02 +0200 (CEST) Received: from BRUNE (brune.prism.uvsq.fr [193.51.25.132]) by guillotin.prism.uvsq.fr (8.11.4/jtpda-5.3.2) with SMTP id h3IAOM104226 ; Fri, 18 Apr 2003 12:24:22 +0200 (MET DST) Message-ID: <102e01c30597$81fbf6c0$841933c1@BRUNE> From: "Ahmed Mehaoua" To: Date: Fri, 18 Apr 2003 12:38:23 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1029_01C305A7.66886D00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Antivirus: scanned by sophie at soleil.uvsq.fr Subject: [MMUSIC] Fw: CFP IEEE/IFIP Intern. Conference on Management of Multimedia Networks & Services 2003 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_1029_01C305A7.66886D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Colleagues,=20 /* PLEASE APOLOGIZE IF YOU RECEIVE MULTIPLE COPIES OF THIS ANNOUNCEMENT = * / /* LAST DAYS FOR ARTICLE SUBMISSIONS TO IFIP/IEEE MMNS 2003 /* THE SUBMISSION DEADLINE IS 18th APRIL 2003 */ Best Regards A. Mehaoua (Univ. of Versailles) ------------------------------------------------------------------- Please distribute to interested people to encourage contributions and = submissions to MMNS 2003 6th IFIP/IEEE International Conference on Management of Multimedia = Networks and Services 7th - 10th September 2003, Queen's University of Belfast, = Northern Ireland=20 http://www.ee.qub.ac.uk/mmns2003=20 Second Call For Papers Multimedia services over IP networks are proliferating at an enormous = speed. There=20 is also increasing demand for solutions which provide assured levels of = service quality.=20 All of these require novel paradigms, models and architectures for = realising integrated=20 end-to-end service management rather than managing network elements in = isolation.=20 Providing scalable Quality of Service (QoS) while maintaining fairness, = along with=20 secure and optimal network resource management are key challenges for = the future=20 Internet. These challenges apply to both fixed and wireless networks.=20 The IFIP/IEEE International Conference on Management of Multimedia = Networks and Services=20 will hold its sixth annual meeting from September 7th to September 10th, = 2003 in Belfast, Northern Ireland. MMNS provides an intimate setting for discussion and = debate. In just 6 years,=20 MMNS has established itself as one of the premier conferences with a = focus on the management=20 of multimedia networks and services. The conference objective is to = bring together researchers=20 working in all facets of network and service management as applied to = broadband networks and=20 multimedia services. MMNS deals with all aspects of designing, = developing and deploying=20 networked multimedia systems and it serves as a forum for the = dissemination of state-of-the-art=20 research and development results.=20 MMNS 2003 will also include panel sessions in which experts=20 offer their observations and opinions about current hot topics. The = keynote speaker will be=20 Professor Ian Akyildiz, Georgia Institute of Technology who will present = a vision of future=20 interplanetary network architectures. Professor Derek McAuley, head of = Intel's recently formed=20 laboratory at Cambridge, UK, will describe some of the new research = being undertaken on global=20 overlay networks and applications. The program committee is soliciting original papers describing research = in the area of=20 management of multimedia networks and services. Topics of interest = include, but are not=20 limited to, the following: * Active multimedia network management=20 * Ad-hoc and Sensor Networks=20 * Augmented and Virtual Reality Networks=20 * Billing and Accounting=20 * Cable multimedia network management=20 * Content distribution internetworking=20 * Deployment of multimedia services=20 * Distributed multimedia service management=20 * End-to-end IP multimedia network and service management=20 * IP Video, streaming, interactive video service management=20 * Middleware support for management=20 * Multimedia network traffic engineering and optimization=20 * Multimedia traffic management=20 * Multimedia content protection=20 * Multimedia session management=20 * Multi-point, multicast services management=20 * Network management models and architectures=20 * Network programmability for multimedia services=20 * Optical multimedia network management=20 * Policy-based management for multi-media services=20 * Provisioning of multimedia networks and services=20 * QoS in WLANs=20 * QoS management=20 * Resource, performance and fault management=20 * Security and Authentication=20 * VoIP service management=20 * Web Services=20 * Wireless and mobile multimedia network management=20 Papers must be submitted electronically in postscript or PDF format. = Detailed=20 instructions are provided on the conference web site, = http://www.ee.qub.ac.uk/mmns2003.=20 Submission date: 18th April 2003 Notification of acceptance: 6th June 2003 Final version: 4th July 2003 Conference Chairs: Professor Alan Marshall, a.marshall@ee.qub.ac.uk, Queen's University = of Belfast, UK Professor Nazim Agoulmine, nazim@rp.lip6.fr, University of Evry, = France ------=_NextPart_000_1029_01C305A7.66886D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Colleagues,
/* PLEASE APOLOGIZE IF YOU RECEIVE = MULTIPLE COPIES=20 OF THIS ANNOUNCEMENT * /
/*  LAST DAYS FOR ARTICLE = SUBMISSIONS TO=20 IFIP/IEEE MMNS 2003
/* THE SUBMISSION DEADLINE IS = 18th APRIL=20 2003 */
Best Regards
A. Mehaoua (Univ. of=20 Versailles)

----------------------------------------------------------------= ---

 Please=20 distribute to interested people to encourage contributions and = submissions to=20 MMNS=20 2003
6th IFIP/IEEE International Conference on Management of = Multimedia Networks and = Services
       =20 7th - 10th September 2003, Queen's University of Belfast, Northern = Ireland=20
           &nb= sp;           &nbs= p;   =20 http://www.ee.qub.ac.uk/mmns2003=20
 

          =             &= nbsp;          =20 Second Call For Papers
 
Multimedia services over IP networks = are=20 proliferating at an enormous speed. There
is also increasing demand = for=20 solutions which provide assured levels of service quality.
All of = these=20 require novel paradigms, models and architectures for realising = integrated=20
end-to-end service management rather than managing network elements = in=20 isolation.
Providing scalable Quality of Service (QoS) while = maintaining=20 fairness, along with
secure and optimal network resource management = are key=20 challenges for the future
Internet. These challenges apply to both = fixed and=20 wireless networks.
 
The IFIP/IEEE International Conference = on=20 Management of Multimedia Networks and Services
will hold its sixth = annual=20 meeting from September 7th to September 10th, 2003 in = Belfast,
Northern=20 Ireland. MMNS provides an intimate setting for discussion and debate. In = just 6=20 years,
MMNS has established itself as one of the premier conferences = with a=20 focus on the management
of multimedia networks and services. The = conference=20 objective is to bring together researchers
working in all facets of = network=20 and service management as applied to broadband networks and =
multimedia=20 services. MMNS deals with all aspects of designing, developing and = deploying=20
networked multimedia systems and it serves as a forum for the = dissemination=20 of state-of-the-art
research and development results.
 
MMNS 2003 will also include panel = sessions in which=20 experts
offer their observations and opinions about current hot = topics. The=20 keynote speaker will be
Professor Ian Akyildiz, Georgia Institute of = Technology who will present a vision of future
interplanetary = network=20 architectures. Professor Derek McAuley, head of Intel's recently formed=20
laboratory at Cambridge, UK, will describe some of the new research = being=20 undertaken on global
overlay networks and applications.
 

The program committee is soliciting = original=20 papers describing research in the area of
management of multimedia = networks=20 and services. Topics of interest include, but are not
limited to, = the=20 following:
 
        * Active=20 multimedia network management =
        *=20 Ad-hoc and Sensor Networks =
        *=20 Augmented and Virtual Reality Networks=20
        * Billing and Accounting=20
        * Cable multimedia = network=20 management
        * Content = distribution=20 internetworking
        * = Deployment of=20 multimedia services
        * = Distributed=20 multimedia service management =
        *=20 End-to-end IP multimedia network and service management=20
        * IP Video, streaming,=20 interactive video service management=20
        * Middleware support for=20 management
        * Multimedia = network=20 traffic engineering and optimization=20
        * Multimedia traffic = management=20
        * Multimedia content = protection=20
        * Multimedia session = management=20
        * Multi-point, multicast = services=20 management
        * Network = management=20 models and architectures
        = *=20 Network programmability for multimedia services=20
        * Optical multimedia = network=20 management
        * Policy-based = management for multi-media services=20
        * Provisioning of = multimedia=20 networks and services
        * = QoS in=20 WLANs
        * QoS management=20
        * Resource, performance = and fault=20 management
        * Security and = Authentication
        * VoIP = service=20 management
        * Web Services =
        * Wireless and mobile = multimedia=20 network management
 

Papers must be submitted = electronically in=20 postscript or PDF format. Detailed
instructions are provided on the=20 conference web site, http://www.ee.qub.ac.uk/mmns2003.
 
Submission=20 date:            18th April 2003
Notification of acceptance: = 6th June=20 2003
Final=20 version:           = ;  =20 4th July 2003
 
Conference Chairs:
   = Professor Alan=20 Marshall, a.marshall@ee.qub.ac.uk, = Queen=92s=20 University of Belfast, UK
   Professor Nazim Agoulmine, = nazim@rp.lip6.fr, = University of Evry,=20 France
 
------=_NextPart_000_1029_01C305A7.66886D00-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 22 23:52:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06184 for ; Tue, 22 Apr 2003 23:52:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N441005324 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 00:04:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N440805321 for ; Wed, 23 Apr 2003 00:04:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06149 for ; Tue, 22 Apr 2003 23:51:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198BKZ-0007T4-00 for mmusic-web-archive@ietf.org; Tue, 22 Apr 2003 23:53:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198BKZ-0007T0-00 for mmusic-web-archive@ietf.org; Tue, 22 Apr 2003 23:53:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N43Y805282; Wed, 23 Apr 2003 00:03:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N42Q805222 for ; Wed, 23 Apr 2003 00:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06102 for ; Tue, 22 Apr 2003 23:50:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198BJ3-0007SE-00 for mmusic@ietf.org; Tue, 22 Apr 2003 23:52:25 -0400 Received: from tog-wakko2.prognet.com ([207.188.29.249] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 198BJ3-0007SB-00 for mmusic@ietf.org; Tue, 22 Apr 2003 23:52:25 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 198BJR-0005pW-00 for ; Tue, 22 Apr 2003 20:52:49 -0700 Date: Tue, 22 Apr 2003 20:52:49 -0700 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20030423035249.GA22348@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/04w6evG8XlLl3ft" Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [MMUSIC] Secure RTSP thoughts Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --/04w6evG8XlLl3ft Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Secure RTSP has been the topic of several conversations recently, both in the telecons and internally at work. I got to thinking about the problem and came up with a possible framework. It's by no means complete, it's just a start. I briefly read the SIP spec recently. SIP has the capability to encrypt portions of the messages. What if we applied that capability to RTSP? We might be able to come up with a backward compatible, firewall friendly, encryption capable protocol. Most of the things that one would want encrypted are in the headers or entity already: the WWW-Authenticate header and the DESCRIBE response entity. Here's an example: DESCRIBE rtsp://media.example.org/video.mpeg RTSP/1.0 CSeq: 1 Content-Type: application/encrypted Content-Length: 27 WWW-Authenticate: foo:bar The WWW-Authenticate header would be sent encrypted. The response might be like this: RTSP/1.0 200 OK CSeq: 1 Date: Wed, 23 Apr 2003 04:36:22 GMT Content-Type: application/encrypted Content-Length: 1344 Content-Base: rtsp://media.example.org/video.mpeg/ Content-Type: application/sdp Content-Length: 1234 v=3D0 ... Here the last three headers and the SDP are encrypted. Note that there is no use in encrypting the Content-Base when the request-uri is sent in the clear. The request-uri could be sent as "*" and a new header in the encrypted section could carry the actual request-uri. We could call this header something tricky like Request-URI. Some headers obviously should never be encrypted. Examples include CSeq, Transport, and Via. A list of such headers would need to be made and included in the spec. Proxies might need special treatment. If one would want to encrypt some data to the proxy and other data to the server, a double encryption might be useful. And finally, we would need to come up with a tag for this feature in the new spec. Thoughts? --=20 Windows 2000: Designed for the Internet. The Internet: Designed for UNIX. --/04w6evG8XlLl3ft Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+pg4RqznSmcYu2m8RAji8AJ4v0Owh0rqBul/kaGqDLFVbK6LdkACghQLz Vm+FM7BAxEo4bjWZxrnTcRI= =73yx -----END PGP SIGNATURE----- --/04w6evG8XlLl3ft-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 00:36:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07613 for ; Wed, 23 Apr 2003 00:36:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N4mWt08687 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 00:48:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4mW808684 for ; Wed, 23 Apr 2003 00:48:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07610 for ; Wed, 23 Apr 2003 00:36:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198C1e-0007fO-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 00:38:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198C1e-0007fL-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 00:38:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4m8808670; Wed, 23 Apr 2003 00:48:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N4lb808654 for ; Wed, 23 Apr 2003 00:47:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07592 for ; Wed, 23 Apr 2003 00:35:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198C0l-0007fE-00 for mmusic@ietf.org; Wed, 23 Apr 2003 00:37:35 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 198C0l-0007f5-00 for mmusic@ietf.org; Wed, 23 Apr 2003 00:37:35 -0400 Received: from dynamicsoft.com ([63.113.46.12]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3N4bVdh000738; Wed, 23 Apr 2003 00:37:31 -0400 (EDT) Message-ID: <3EA61886.9090605@dynamicsoft.com> Date: Wed, 23 Apr 2003 00:37:26 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] Secure RTSP thoughts References: <20030423035249.GA22348@real.com> In-Reply-To: <20030423035249.GA22348@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit You are basically talking about using S/MIME. S/MIME is useful in SIP because of its peer-to-peer nature. But, it comes at a high cost - the requirement to have a PKI. Especially for encryption, where you need the key of the recipient. If RTSP is focusing now on the client/server model exclusively (per our nat debate), I would think that TLS is a better match. Doing the equivalent of sips - rtsps - would be much more deployable, since it would not require some additional key distribution mechanism. -Jonathan R. Tom Marshall wrote: > Secure RTSP has been the topic of several conversations recently, both > in > the telecons and internally at work. I got to thinking about the > problem > and came up with a possible framework. It's by no means complete, it's > just > a start. > > I briefly read the SIP spec recently. SIP has the capability to encrypt > portions of the messages. What if we applied that capability to RTSP? > We > might be able to come up with a backward compatible, firewall friendly, > encryption capable protocol. Most of the things that one would want > encrypted are in the headers or entity already: the WWW-Authenticate > header > and the DESCRIBE response entity. Here's an example: > > DESCRIBE rtsp://media.example.org/video.mpeg RTSP/1.0 > CSeq: 1 > Content-Type: application/encrypted > Content-Length: 27 > > WWW-Authenticate: foo:bar > > The WWW-Authenticate header would be sent encrypted. The response might > be > like this: > > RTSP/1.0 200 OK > CSeq: 1 > Date: Wed, 23 Apr 2003 04:36:22 GMT > Content-Type: application/encrypted > Content-Length: 1344 > > Content-Base: rtsp://media.example.org/video.mpeg/ > Content-Type: application/sdp > Content-Length: 1234 > > v=0 > ... > > Here the last three headers and the SDP are encrypted. Note that there > is > no use in encrypting the Content-Base when the request-uri is sent in > the > clear. The request-uri could be sent as "*" and a new header in the > encrypted section could carry the actual request-uri. We could call > this > header something tricky like Request-URI. > > Some headers obviously should never be encrypted. Examples include > CSeq, > Transport, and Via. A list of such headers would need to be made and > included in the spec. > > Proxies might need special treatment. If one would want to encrypt some > data to the proxy and other data to the server, a double encryption > might be > useful. > > And finally, we would need to come up with a tag for this feature in the > new > spec. > > Thoughts? > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 00:56:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07840 for ; Wed, 23 Apr 2003 00:56:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N58HN10133 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 01:08:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N58H810130 for ; Wed, 23 Apr 2003 01:08:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07836 for ; Wed, 23 Apr 2003 00:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198CKl-0007j1-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 00:58:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198CKk-0007iy-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 00:58:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N58C810121; Wed, 23 Apr 2003 01:08:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N57R809887 for ; Wed, 23 Apr 2003 01:07:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07830 for ; Wed, 23 Apr 2003 00:55:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198CJw-0007ie-00 for mmusic@ietf.org; Wed, 23 Apr 2003 00:57:24 -0400 Received: from tog-wakko2.prognet.com ([207.188.29.249] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 198CJw-0007ia-00 for mmusic@ietf.org; Wed, 23 Apr 2003 00:57:24 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 198CKB-0005sR-00; Tue, 22 Apr 2003 21:57:39 -0700 Date: Tue, 22 Apr 2003 21:57:39 -0700 From: Tom Marshall To: Jonathan Rosenberg Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Secure RTSP thoughts Message-ID: <20030423045739.GA22517@real.com> References: <20030423035249.GA22348@real.com> <3EA61886.9090605@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <3EA61886.9090605@dynamicsoft.com> User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 23, 2003 at 12:37:26AM -0400, Jonathan Rosenberg wrote: > You are basically talking about using S/MIME. >=20 > S/MIME is useful in SIP because of its peer-to-peer nature. But, it=20 > comes at a high cost - the requirement to have a PKI. Especially for=20 > encryption, where you need the key of the recipient. There must be some way to make it work reasonably well. I am not an encryption expert, but I can start reading up on it. > If RTSP is focusing now on the client/server model exclusively (per our= =20 > nat debate), I would think that TLS is a better match. Doing the=20 > equivalent of sips - rtsps - would be much more deployable, since it=20 > would not require some additional key distribution mechanism. We may focus on client/server but RTSP does have peer-to-peer uses. Doesn't TLS encrypt all of the data? I think that is quite undesirable.=20 You lose the ability to use ALGs and existing RTSP proxies. --=20 The problem with most conspiracy theories is that they seem to believe that for a group of people to behave in a way detrimental to the common good requires intent. --0F1p//8PRICkK4MW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+ph1DqznSmcYu2m8RAoXqAJ9IqOf79QkC9yBab1t124v9XVZBLwCfR+64 bD2PTiGKRounZE+zB7uTFMM= =yln4 -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 03:56:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06971 for ; Wed, 23 Apr 2003 03:56:55 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N88qt01763 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 04:08:52 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N88p801760 for ; Wed, 23 Apr 2003 04:08:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06941 for ; Wed, 23 Apr 2003 03:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198F9R-0001AA-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 03:58:45 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198F9R-0001A7-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 03:58:45 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N88A801663; Wed, 23 Apr 2003 04:08:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N7xS832501 for ; Wed, 23 Apr 2003 03:59:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06671 for ; Wed, 23 Apr 2003 03:47:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198F0M-00015a-00 for mmusic@ietf.org; Wed, 23 Apr 2003 03:49:22 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 198F0L-00015X-00 for mmusic@ietf.org; Wed, 23 Apr 2003 03:49:22 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3N7njI3027212 for ; Wed, 23 Apr 2003 09:49:45 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JPPC88WJ; Wed, 23 Apr 2003 09:49:47 +0200 Message-ID: <3EA64562.2070608@era.ericsson.se> Date: Wed, 23 Apr 2003 09:48:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] Secure RTSP thoughts References: <20030423045739.GA22517@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Tom, It seems evident that we must start discussing what we want to accomplish with securing the RTSP messages. Some requirements on what I see as necessary for transport secured RTSP: + Message authentication to prevent tampering. In my opinion we must authenticate the whole message to provide any benefit. This will create problems with ALGs and Proxies. The Transport header is a vital header for RTSP functionality and it is desired to have it secured, and at the same time it is the header that an proxy or ALG needs to both read and possibly change. + Message privacy, I don't know what parts we actually need to have encrypted. There is several issues here, user privacy, preventing disclosure of information that an attacker could use. What should the security architecture be? Do we need two levels, one between each entity, i.e. between client and proxy and then proxy to server. Then a second level that is protected end to end, i.e. client <-> server. I think we should get a security advisor for this. One knowledgeable about these issues would be very good. Colin and Joerg: Who is our security advisor? >>If RTSP is focusing now on the client/server model exclusively (per >> >> >our > > >>nat debate), I would think that TLS is a better match. Doing the >>equivalent of sips - rtsps - would be much more deployable, since it >>would not require some additional key distribution mechanism. >> >> > >We may focus on client/server but RTSP does have peer-to-peer uses. > >Doesn't TLS encrypt all of the data? I think that is quite undesirable. > >You lose the ability to use ALGs and existing RTSP proxies. > > As pointed out above, I think we need to think about what we would like to accomplish. We need to review what security we need and what is possible to fit into this. I think we will have to face some hard decisions before the end of this work. Would a proxy really be able to handle such a message you propose. One bug I see is that the proxy needs at least the host part of the request URI to be able to send the request to the correct entity. And if you need trusted proxies, I think one actually needs consider that these proxies must be updated and security audited. I get the feeling that using TLS is rather simple but requires a limited usage model or trusted proxies. And as proxies can't really be trusted, what do we do? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 08:08:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14852 for ; Wed, 23 Apr 2003 08:08:52 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NCKr319317 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 08:20:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCKq819314 for ; Wed, 23 Apr 2003 08:20:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14845 for ; Wed, 23 Apr 2003 08:08:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198J5F-0003BE-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 08:10:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198J5E-0003BB-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 08:10:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCKC819299; Wed, 23 Apr 2003 08:20:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3MCHn832441 for ; Tue, 22 Apr 2003 08:17:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04554 for ; Tue, 22 Apr 2003 08:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197wZE-0000eo-00 for mmusic@ietf.org; Tue, 22 Apr 2003 08:08:08 -0400 Received: from ingegneria.unime.it ([192.167.96.190]) by ietf-mx with esmtp (Exim 4.12) id 197wZD-0000eX-00 for mmusic@ietf.org; Tue, 22 Apr 2003 08:08:07 -0400 Received: from galileo (defran.unime.it [192.167.96.81]) by ingegneria.unime.it (8.12.8/8.12.5) with SMTP id h3MC8wco002847 for ; Tue, 22 Apr 2003 14:08:59 +0200 Message-ID: <003301c308c7$d2003950$5160a7c0@saoe.com> From: "Amedeo Michelin-Salomon" To: Date: Tue, 22 Apr 2003 14:08:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Help rtp Timestamp Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi,I have read your post on ucb.digital-video. I'm a Italian Student of Eletronical Engineering....I have develop a application for VOD on Wireless System.....I have a problem to calculate the NTP of the clip for a fix Timestamp.....do you have a solution for this problem? i have read that NTP = (LastTimestam-FirstTimestam)/frequency but i don't know how get this frequency.... thanx for help AMS Michelin@ingegneria.unime.it P.s. my application in over RTSP on RTP _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 08:20:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15273 for ; Wed, 23 Apr 2003 08:20:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NCW9B19878 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 08:32:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCW9819875 for ; Wed, 23 Apr 2003 08:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15258 for ; Wed, 23 Apr 2003 08:19:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198JG9-0003G0-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 08:21:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198JG9-0003Fx-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 08:21:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCW7819863; Wed, 23 Apr 2003 08:32:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NCVB819767 for ; Wed, 23 Apr 2003 08:31:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15095 for ; Wed, 23 Apr 2003 08:18:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198JFD-0003FG-00 for mmusic@ietf.org; Wed, 23 Apr 2003 08:20:59 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 198JFD-0003FD-00 for mmusic@ietf.org; Wed, 23 Apr 2003 08:20:59 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3NCLNRs015188 for ; Wed, 23 Apr 2003 14:21:23 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JPSH4GF8; Wed, 23 Apr 2003 14:21:25 +0200 Message-ID: <3EA6850C.1070301@era.ericsson.se> Date: Wed, 23 Apr 2003 14:20:28 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP telecon 28 of Apri - Note date. Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is the agenda for MONDAY's RTSP telecon at 18.00 CET (GMT+2). Details of the meeting is sent on the RTSP logistics list. If you are not part of the list and want to participate, please send me a mail. Regards Magnus ---------------------------- Agenda 030428 1. Opening of meeting. 2. Since last meeting (16th of April). a. http://rtsp.org/bug513737 - Waiting for write up. b. Bug 533691 & 513880 - Aravind to write up, progress? - Issue with range header in Scale=-1 c. http://rtsp.org/bug556295 - Thomas to write text. d. Stream switching requirements document (Phillipe Gentric) e. Offer Answer for RTSP. Anybody willing to write requirements and use case? - Andrea Basso or Phillipe Gentric? f. Ways to allow direct media destination to other than own IP address. (Phillipe Gentric) g. Multiple SSRC in RTSP. - Conclusion explain what is supported today. That given SSRC in transport header is connected to RTP-Info. Use RTCP for other media streams or develop a extension - Aravind to write updated text. h. How to distinguish the updated specification. Please read up on how versions are handled in the HTTP specification. i. Warning header: For further discussion. j. RTSP servers behind NATs. Use case seems to exist. Requires someone to write scenario document. Decide on how to go forward compared with public network servers. Time line considerations. k. RTSP ALG for Linux netfilter. (Tom Marshall) 3. New Things a. http://rtsp.org/bug631148 better Info on RTSP proxies. b. http://rtsp.org/bug631957 Use of # and ? in RTSP URLs? c. http://rtsp.org/bug633148 Use of TCP and UDP. d. http://rtsp.org/bug633779 SET_PARAMETER responses. 5. Any other Issues 6. Next meeting 7. End meeting -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 09:53:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18574 for ; Wed, 23 Apr 2003 09:53:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NE5BX26879 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 10:05:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NE5B826876 for ; Wed, 23 Apr 2003 10:05:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18525 for ; Wed, 23 Apr 2003 09:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198Ki9-0003xw-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 09:54:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198Ki9-0003xt-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 09:54:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NE57826868; Wed, 23 Apr 2003 10:05:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NE4L826816 for ; Wed, 23 Apr 2003 10:04:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18505 for ; Wed, 23 Apr 2003 09:51:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198KhL-0003xW-00 for mmusic@ietf.org; Wed, 23 Apr 2003 09:54:07 -0400 Received: from wireless228.east.isi.edu ([65.123.202.228] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 198KhL-0003xT-00 for mmusic@ietf.org; Wed, 23 Apr 2003 09:54:07 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3NDsQGt070698; Wed, 23 Apr 2003 09:54:26 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304231354.h3NDsQGt070698@purple.nge.isi.edu> To: Magnus Westerlund cc: mmusic@ietf.org Subject: Re: [MMUSIC] Secure RTSP thoughts In-Reply-To: Your message of "Wed, 23 Apr 2003 09:48:50 +0200." <3EA64562.2070608@era.ericsson.se> Date: Wed, 23 Apr 2003 09:54:26 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> Magnus Westerlund writes: >Hi Tom, > >It seems evident that we must start discussing what we want to >accomplish with securing the RTSP messages. > >Some requirements on what I see as necessary for transport secured RTSP: > >+ Message authentication to prevent tampering. In my opinion we must >authenticate the whole message to provide any benefit. This will create >problems with ALGs and Proxies. The Transport header is a vital header >for RTSP functionality and it is desired to have it secured, and at the >same time it is the header that an proxy or ALG needs to both read and >possibly change. > >+ Message privacy, I don't know what parts we actually need to have >encrypted. There is several issues here, user privacy, preventing >disclosure of information that an attacker could use. > >What should the security architecture be? Do we need two levels, one >between each entity, i.e. between client and proxy and then proxy to >server. Then a second level that is protected end to end, i.e. client ><-> server. > >I think we should get a security advisor for this. One knowledgeable >about these issues would be very good. > >Colin and Joerg: Who is our security advisor? Eric Rescorla. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 23 16:53:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06632 for ; Wed, 23 Apr 2003 16:53:19 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NKtbd30143 for mmusic-archive@odin.ietf.org; Wed, 23 Apr 2003 16:55:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKtb830140 for ; Wed, 23 Apr 2003 16:55:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06616 for ; Wed, 23 Apr 2003 16:52:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198RGn-0007MJ-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 16:55:09 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198RGn-0007MG-00 for mmusic-web-archive@ietf.org; Wed, 23 Apr 2003 16:55:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKtF830127; Wed, 23 Apr 2003 16:55:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NKsL830082 for ; Wed, 23 Apr 2003 16:54:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06570 for ; Wed, 23 Apr 2003 16:51:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198RFZ-0007Ly-00 for mmusic@ietf.org; Wed, 23 Apr 2003 16:53:53 -0400 Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 198RFZ-0007Lv-00 for mmusic@ietf.org; Wed, 23 Apr 2003 16:53:53 -0400 Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.9/8.12.5) with ESMTP id h3NKsIRG003481 for ; Wed, 23 Apr 2003 13:54:18 -0700 (PDT) (envelope-from rsf@ns.live.com) Received: (from rsf@localhost) by ns.live.com (8.12.9/8.12.3/Submit) id h3NKsIAq003478; Wed, 23 Apr 2003 13:54:18 -0700 (PDT) Message-Id: <4.3.1.1.20030423134211.00c5a100@laptop-localhost> X-Sender: rsf@laptop-localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 23 Apr 2003 13:54:05 -0700 To: mmusic@ietf.org From: Ross Finlayson Subject: Re: [MMUSIC] Secure RTSP thoughts In-Reply-To: <3EA64562.2070608@era.ericsson.se> References: <20030423045739.GA22517@real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At 12:48 AM 4/23/03, Magnus Westerlund wrote: >What should the security architecture be? Do we need two levels, one >between each entity, i.e. between client and proxy and then proxy to >server. Then a second level that is protected end to end, i.e. client <-> >server. One possible approach would be for us to *first* specify an end-to-end security solution - e.g., using TLS ("rtsps://"). Although this would not work with ALGs and proxies, it would be relatively easy to do (building on existing work), and be very useful. In the longer term, we could also look at the more complex problem of defining an alternative, multi-layered solution that would work with ALGs/proxies. >+ Message privacy, I don't know what parts we actually need to have >encrypted. One clear requirement is to encrypt the SDP description that gets returned in response to a "DESCRIBE", because that will contain decryption keys (if SRTP is to be used for media transport). I think that a TLS-based solution - even though it would work only end-to-end - would be a good starting point, and it would help make RTSP/SRTP streaming a reality fairly quickly. >I think we should get a security advisor for this. One knowledgeable about >these issues would be very good. Yes - definitely! Ross. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 24 18:19:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08072 for ; Thu, 24 Apr 2003 18:19:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3OMMYM17327 for mmusic-archive@odin.ietf.org; Thu, 24 Apr 2003 18:22:34 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMMY817324 for ; Thu, 24 Apr 2003 18:22:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08069 for ; Thu, 24 Apr 2003 18:19:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198p5y-0002KH-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 18:21:34 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198p5x-0002KD-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 18:21:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMMS817314; Thu, 24 Apr 2003 18:22:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3OMLv817281 for ; Thu, 24 Apr 2003 18:21:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08047 for ; Thu, 24 Apr 2003 18:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198p5M-0002K1-00 for mmusic@ietf.org; Thu, 24 Apr 2003 18:20:56 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 198p5M-0002Jr-00 for mmusic@ietf.org; Thu, 24 Apr 2003 18:20:56 -0400 Received: from cscoamera13263.cisco.com (rtp-vpn2-1094.cisco.com [10.82.244.70]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3OMKm09025896; Thu, 24 Apr 2003 15:20:50 -0700 (PDT) Message-Id: <5.1.1.5.2.20030424145814.0ae4c008@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 24 Apr 2003 15:20:45 -0700 To: Magnus Westerlund From: Mark Baugher Subject: Re: [MMUSIC] Secure RTSP thoughts Cc: mmusic@ietf.org In-Reply-To: <3EA64562.2070608@era.ericsson.se> References: <20030423045739.GA22517@real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus This reminds me of a topic that you raised at the last meeting: We need to define RTSP-over-SSL/TLS. I don't understand what needs to be defined outside of ALGs/proxies, which break the end-to-end security model and are a special problem for other protocols - notably SIP. Are your concerns limited to ALGs/proxies? Mark At 09:48 AM 4/23/2003 +0200, Magnus Westerlund wrote: >Hi Tom, > >It seems evident that we must start discussing what we want to accomplish >with securing the RTSP messages. > >Some requirements on what I see as necessary for transport secured RTSP: > >+ Message authentication to prevent tampering. In my opinion we must >authenticate the whole message to provide any benefit. This will create >problems with ALGs and Proxies. The Transport header is a vital header for >RTSP functionality and it is desired to have it secured, and at the same >time it is the header that an proxy or ALG needs to both read and possibly >change. > >+ Message privacy, I don't know what parts we actually need to have >encrypted. There is several issues here, user privacy, preventing >disclosure of information that an attacker could use. > >What should the security architecture be? Do we need two levels, one >between each entity, i.e. between client and proxy and then proxy to >server. Then a second level that is protected end to end, i.e. client <-> >server. > >I think we should get a security advisor for this. One knowledgeable about >these issues would be very good. > >Colin and Joerg: Who is our security advisor? > >>>If RTSP is focusing now on the client/server model exclusively (per >>> >>our >>>nat debate), I would think that TLS is a better match. Doing the >>>equivalent of sips - rtsps - would be much more deployable, since it >>>would not require some additional key distribution mechanism. >>> >> >>We may focus on client/server but RTSP does have peer-to-peer uses. >> >>Doesn't TLS encrypt all of the data? I think that is quite undesirable. >> >>You lose the ability to use ALGs and existing RTSP proxies. >> >As pointed out above, I think we need to think about what we would like to >accomplish. We need to review what security we need and what is possible >to fit into this. I think we will have to face some hard decisions before >the end of this work. Would a proxy really be able to handle such a >message you propose. One bug I see is that the proxy needs at least the >host part of the request URI to be able to send the request to the correct >entity. And if you need trusted proxies, I think one actually needs >consider that these proxies must be updated and security audited. > >I get the feeling that using TLS is rather simple but requires a limited >usage model or trusted proxies. And as proxies can't really be trusted, >what do we do? > > >Best Regards > >Magnus Westerlund >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 24 21:20:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12354 for ; Thu, 24 Apr 2003 21:20:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P1NVU29603 for mmusic-archive@odin.ietf.org; Thu, 24 Apr 2003 21:23:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1NV829600 for ; Thu, 24 Apr 2003 21:23:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12347 for ; Thu, 24 Apr 2003 21:20:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198rv1-0003fz-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:22:27 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198rv0-0003fw-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:22:26 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1NK829592; Thu, 24 Apr 2003 21:23:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1M0829529 for ; Thu, 24 Apr 2003 21:22:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12310 for ; Thu, 24 Apr 2003 21:18:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198rtY-0003fc-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:20:56 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 198rtX-0003fI-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:20:55 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h3P1Kjqq082178 for ; Thu, 24 Apr 2003 18:20:45 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 18:20:45 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A79F1@MISTY> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Thu, 24 Apr 2003 18:20:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RTSP client issues PAUSE while server ready Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Hello, MMUSIC: During last weeks RTSP teleconf, I took the action to report a tentative resolution to everyone on MMUSIC mailing list. This issue is reported in: http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377 744&aid=556295 If a client issues a PAUSE and the server acknowledges and enters ready state, what is proper server response if the player issues another PAUSE? The tentative agreement is to have RTSP server send back 200 OK in this case, even though no action is taken by the server. Are there any objections from anyone? Thanks, - thomas _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 24 21:27:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12458 for ; Thu, 24 Apr 2003 21:27:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P1U7N29903 for mmusic-archive@odin.ietf.org; Thu, 24 Apr 2003 21:30:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1U7829900 for ; Thu, 24 Apr 2003 21:30:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12452 for ; Thu, 24 Apr 2003 21:26:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198s1P-0003iV-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:29:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198s1O-0003iS-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:29:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1U3829892; Thu, 24 Apr 2003 21:30:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1Ts829861 for ; Thu, 24 Apr 2003 21:29:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12449 for ; Thu, 24 Apr 2003 21:26:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198s1C-0003iP-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:28:50 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 198s1B-0003iG-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:28:49 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h3P1Slqq082301 for ; Thu, 24 Apr 2003 18:28:47 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 18:28:47 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A79F2@MISTY> From: Thomas Zeng To: mmusic@ietf.org Subject: RE: [MMUSIC] Secure RTSP thoughts Date: Thu, 24 Apr 2003 18:28:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Mark: So far concerns seem to be limited to ALGs/proxies. Having said that, in the case of HTTP, there is the informative RFC2818 "HTTP Over TLS" which describes how to use HTTP over TLS. See: I wonder whether similar RFC on "RTSP over TLS" is needed? - thomas -----Original Message----- From: Mark Baugher [mailto:mbaugher@cisco.com] Sent: Thursday, April 24, 2003 3:21 PM To: Magnus Westerlund Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Secure RTSP thoughts Magnus This reminds me of a topic that you raised at the last meeting: We need to define RTSP-over-SSL/TLS. I don't understand what needs to be defined outside of ALGs/proxies, which break the end-to-end security model and are a special problem for other protocols - notably SIP. Are your concerns limited to ALGs/proxies? Mark At 09:48 AM 4/23/2003 +0200, Magnus Westerlund wrote: >Hi Tom, > >It seems evident that we must start discussing what we want to accomplish >with securing the RTSP messages. > >Some requirements on what I see as necessary for transport secured RTSP: > >+ Message authentication to prevent tampering. In my opinion we must >authenticate the whole message to provide any benefit. This will create >problems with ALGs and Proxies. The Transport header is a vital header for >RTSP functionality and it is desired to have it secured, and at the same >time it is the header that an proxy or ALG needs to both read and possibly >change. > >+ Message privacy, I don't know what parts we actually need to have >encrypted. There is several issues here, user privacy, preventing >disclosure of information that an attacker could use. > >What should the security architecture be? Do we need two levels, one >between each entity, i.e. between client and proxy and then proxy to >server. Then a second level that is protected end to end, i.e. client <-> >server. > >I think we should get a security advisor for this. One knowledgeable about >these issues would be very good. > >Colin and Joerg: Who is our security advisor? > >>>If RTSP is focusing now on the client/server model exclusively (per >>> >>our >>>nat debate), I would think that TLS is a better match. Doing the >>>equivalent of sips - rtsps - would be much more deployable, since it >>>would not require some additional key distribution mechanism. >>> >> >>We may focus on client/server but RTSP does have peer-to-peer uses. >> >>Doesn't TLS encrypt all of the data? I think that is quite undesirable. >> >>You lose the ability to use ALGs and existing RTSP proxies. >> >As pointed out above, I think we need to think about what we would like to >accomplish. We need to review what security we need and what is possible >to fit into this. I think we will have to face some hard decisions before >the end of this work. Would a proxy really be able to handle such a >message you propose. One bug I see is that the proxy needs at least the >host part of the request URI to be able to send the request to the correct >entity. And if you need trusted proxies, I think one actually needs >consider that these proxies must be updated and security audited. > >I get the feeling that using TLS is rather simple but requires a limited >usage model or trusted proxies. And as proxies can't really be trusted, >what do we do? > > >Best Regards > >Magnus Westerlund >Multimedia Technologies, Ericsson Research ERA/TVA/A >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >Torshamsgatan 23 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ 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 mailnull@www1.ietf.org Thu Apr 24 21:38:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12597 for ; Thu, 24 Apr 2003 21:38:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P1fJH31192 for mmusic-archive@odin.ietf.org; Thu, 24 Apr 2003 21:41:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1fJ831189 for ; Thu, 24 Apr 2003 21:41:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12584 for ; Thu, 24 Apr 2003 21:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sCF-0003lM-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:40:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198sCE-0003lJ-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 21:40:14 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1fB831179; Thu, 24 Apr 2003 21:41:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P1e9831144 for ; Thu, 24 Apr 2003 21:40:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12563 for ; Thu, 24 Apr 2003 21:36:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198sB7-0003ky-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:39:05 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 198sB6-0003ku-00 for mmusic@ietf.org; Thu, 24 Apr 2003 21:39:04 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h3P1d2qq082441 for ; Thu, 24 Apr 2003 18:39:02 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Apr 2003 18:39:02 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A79F3@MISTY> From: Thomas Zeng To: "'mmusic@ietf.org'" Date: Thu, 24 Apr 2003 18:39:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] How to identify the updated RTSP specification ? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Dear MMUSIC Mailing List: During last week's RTSP teleconference, we had a discussion on how to distinguish the updated RTSP (i.e., the ongoing work around draft-ietf-mmusic-rfc2326bis-03.txt, see http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf). There is enough change on the table that we feel version number should be increased to avoid confusion when RTSP server and client might be implementing the old (rfc2326) and the new RTSP spec (will be a new RFC). Should we increase the minor version to say RTSP/1.1, or should we up the major version (to say RTSP/2.0)? Your comments are welcome. Thanks, thomas _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Thu Apr 24 22:59:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13879 for ; Thu, 24 Apr 2003 22:59:37 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P32Vp04109 for mmusic-archive@odin.ietf.org; Thu, 24 Apr 2003 23:02:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P32V804106 for ; Thu, 24 Apr 2003 23:02:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13876 for ; Thu, 24 Apr 2003 22:59:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198tSm-0004BS-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 23:01:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198tSm-0004BP-00 for mmusic-web-archive@ietf.org; Thu, 24 Apr 2003 23:01:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P32O804098; Thu, 24 Apr 2003 23:02:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P31X804065 for ; Thu, 24 Apr 2003 23:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13872 for ; Thu, 24 Apr 2003 22:58:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198tRr-0004BK-00 for mmusic@ietf.org; Thu, 24 Apr 2003 23:00:27 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by ietf-mx with esmtp (Exim 4.12) id 198tRq-0004BE-00 for mmusic@ietf.org; Thu, 24 Apr 2003 23:00:26 -0400 Received: from cscoamera13263.cisco.com (rtp-vpn2-1094.cisco.com [10.82.244.70]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3P30IlZ028894; Thu, 24 Apr 2003 23:00:19 -0400 (EDT) Message-Id: <5.1.1.5.2.20030424195501.0af02588@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 24 Apr 2003 20:00:17 -0700 To: Thomas Zeng From: Mark Baugher Subject: RE: [MMUSIC] Secure RTSP thoughts Cc: mmusic@ietf.org In-Reply-To: <72263E8E8622D611975C0002B32C19D84A79F2@MISTY> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Thomas, At 06:28 PM 4/24/2003 -0700, Thomas Zeng wrote: >Mark: > >So far concerns seem to be limited to ALGs/proxies. > >Having said that, in the case of HTTP, there is the informative RFC2818 >"HTTP Over TLS" which describes how to use HTTP over TLS. See: > >I wonder whether similar RFC on "RTSP over TLS" is needed? Perhaps an informational or BCP document would be useful or even necessary. But I expect that it would recommend that we don't use TLS/SSL to proxies (or whenever the endpoint of the SSL connection isn't coincident with the endpoint of the RTSP connection). Seems to me that the proxy security problem is a different barrel of monkeys. Mark >- thomas > > >-----Original Message----- >From: Mark Baugher [mailto:mbaugher@cisco.com] >Sent: Thursday, April 24, 2003 3:21 PM >To: Magnus Westerlund >Cc: mmusic@ietf.org >Subject: Re: [MMUSIC] Secure RTSP thoughts > > >Magnus > This reminds me of a topic that you raised at the last meeting: We need >to define RTSP-over-SSL/TLS. I don't understand what needs to be defined >outside of ALGs/proxies, which break the end-to-end security model and are >a special problem for other protocols - notably SIP. > > Are your concerns limited to ALGs/proxies? > >Mark >At 09:48 AM 4/23/2003 +0200, Magnus Westerlund wrote: > >Hi Tom, > > > >It seems evident that we must start discussing what we want to accomplish > >with securing the RTSP messages. > > > >Some requirements on what I see as necessary for transport secured RTSP: > > > >+ Message authentication to prevent tampering. In my opinion we must > >authenticate the whole message to provide any benefit. This will create > >problems with ALGs and Proxies. The Transport header is a vital header for > >RTSP functionality and it is desired to have it secured, and at the same > >time it is the header that an proxy or ALG needs to both read and possibly > >change. > > > >+ Message privacy, I don't know what parts we actually need to have > >encrypted. There is several issues here, user privacy, preventing > >disclosure of information that an attacker could use. > > > >What should the security architecture be? Do we need two levels, one > >between each entity, i.e. between client and proxy and then proxy to > >server. Then a second level that is protected end to end, i.e. client <-> > >server. > > > >I think we should get a security advisor for this. One knowledgeable about > >these issues would be very good. > > > >Colin and Joerg: Who is our security advisor? > > > >>>If RTSP is focusing now on the client/server model exclusively (per > >>> > >>our > >>>nat debate), I would think that TLS is a better match. Doing the > >>>equivalent of sips - rtsps - would be much more deployable, since it > >>>would not require some additional key distribution mechanism. > >>> > >> > >>We may focus on client/server but RTSP does have peer-to-peer uses. > >> > >>Doesn't TLS encrypt all of the data? I think that is quite undesirable. > >> > >>You lose the ability to use ALGs and existing RTSP proxies. > >> > >As pointed out above, I think we need to think about what we would like to > >accomplish. We need to review what security we need and what is possible > >to fit into this. I think we will have to face some hard decisions before > >the end of this work. Would a proxy really be able to handle such a > >message you propose. One bug I see is that the proxy needs at least the > >host part of the request URI to be able to send the request to the correct > >entity. And if you need trusted proxies, I think one actually needs > >consider that these proxies must be updated and security audited. > > > >I get the feeling that using TLS is rather simple but requires a limited > >usage model or trusted proxies. And as proxies can't really be trusted, > >what do we do? > > > > > >Best Regards > > > >Magnus Westerlund > >Multimedia Technologies, Ericsson Research ERA/TVA/A > >---------------------------------------------------------------------- > >Ericsson AB | Phone +46 8 4048287 > >Torshamsgatan 23 | Fax +46 8 7575550 > >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 04:29:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00438 for ; Fri, 25 Apr 2003 04:29:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3P8WAV04566 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 04:32:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P8WA804563 for ; Fri, 25 Apr 2003 04:32:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00419 for ; Fri, 25 Apr 2003 04:28:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198ybh-00063J-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 04:30:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198ybg-00063G-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 04:30:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P8VP804522; Fri, 25 Apr 2003 04:31:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3P8Ui804450 for ; Fri, 25 Apr 2003 04:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00408 for ; Fri, 25 Apr 2003 04:27:13 -0400 (EDT) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198yaJ-00062z-00 for mmusic@ietf.org; Fri, 25 Apr 2003 04:29:31 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 198yaI-00062w-00 for mmusic@ietf.org; Fri, 25 Apr 2003 04:29:31 -0400 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h3P8TwD09892 for ; Fri, 25 Apr 2003 11:29:58 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 25 Apr 2003 11:29:55 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 11:29:55 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 25 Apr 2003 11:29:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [MMUSIC] Secure RTSP thoughts Date: Fri, 25 Apr 2003 11:29:54 +0300 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD90194523A@esebe013.ntc.nokia.com> Thread-Topic: [MMUSIC] Secure RTSP thoughts Thread-Index: AcMK1xdy92a7X3kkTE+e35/7T+wzXAALMwMg To: , Cc: X-OriginalArrivalTime: 25 Apr 2003 08:29:55.0227 (UTC) FILETIME=[D96FE6B0:01C30B04] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3P8Ui804452 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, > -----Original Message----- > From: ext Mark Baugher [mailto:mbaugher@cisco.com] > Sent: 25 April, 2003 06:00 > To: Thomas Zeng > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] Secure RTSP thoughts > > > Thomas, > > At 06:28 PM 4/24/2003 -0700, Thomas Zeng wrote: > >Mark: > > > >So far concerns seem to be limited to ALGs/proxies. > > > >Having said that, in the case of HTTP, there is the > informative RFC2818 > >"HTTP Over TLS" which describes how to use HTTP over TLS. See: > > > >I wonder whether similar RFC on "RTSP over TLS" is needed? > > Perhaps an informational or BCP document would be useful or even > necessary. But I expect that it would recommend that we > don't use TLS/SSL > to proxies (or whenever the endpoint of the SSL connection > isn't coincident > with the endpoint of the RTSP connection). Seems to me that > the proxy > security problem is a different barrel of monkeys. I think you're right. For HTTP, RFC 2818 solves a separate problem from RFC 2817, which actually describes how TLS can be tunneled through proxies and how a TCP connection can be upgraded to TLS. Cheers, Aki > > Mark > > > >- thomas > > > > > >-----Original Message----- > >From: Mark Baugher [mailto:mbaugher@cisco.com] > >Sent: Thursday, April 24, 2003 3:21 PM > >To: Magnus Westerlund > >Cc: mmusic@ietf.org > >Subject: Re: [MMUSIC] Secure RTSP thoughts > > > > > >Magnus > > This reminds me of a topic that you raised at the last > meeting: We need > >to define RTSP-over-SSL/TLS. I don't understand what needs > to be defined > >outside of ALGs/proxies, which break the end-to-end > security model and are > >a special problem for other protocols - notably SIP. > > > > Are your concerns limited to ALGs/proxies? > > > >Mark > >At 09:48 AM 4/23/2003 +0200, Magnus Westerlund wrote: > > >Hi Tom, > > > > > >It seems evident that we must start discussing what we > want to accomplish > > >with securing the RTSP messages. > > > > > >Some requirements on what I see as necessary for > transport secured RTSP: > > > > > >+ Message authentication to prevent tampering. In my > opinion we must > > >authenticate the whole message to provide any benefit. > This will create > > >problems with ALGs and Proxies. The Transport header is a > vital header for > > >RTSP functionality and it is desired to have it secured, > and at the same > > >time it is the header that an proxy or ALG needs to both > read and possibly > > >change. > > > > > >+ Message privacy, I don't know what parts we actually > need to have > > >encrypted. There is several issues here, user privacy, preventing > > >disclosure of information that an attacker could use. > > > > > >What should the security architecture be? Do we need two > levels, one > > >between each entity, i.e. between client and proxy and > then proxy to > > >server. Then a second level that is protected end to end, > i.e. client <-> > > >server. > > > > > >I think we should get a security advisor for this. One > knowledgeable about > > >these issues would be very good. > > > > > >Colin and Joerg: Who is our security advisor? > > > > > >>>If RTSP is focusing now on the client/server model > exclusively (per > > >>> > > >>our > > >>>nat debate), I would think that TLS is a better match. Doing the > > >>>equivalent of sips - rtsps - would be much more > deployable, since it > > >>>would not require some additional key distribution mechanism. > > >>> > > >> > > >>We may focus on client/server but RTSP does have > peer-to-peer uses. > > >> > > >>Doesn't TLS encrypt all of the data? I think that is > quite undesirable. > > >> > > >>You lose the ability to use ALGs and existing RTSP proxies. > > >> > > >As pointed out above, I think we need to think about what > we would like to > > >accomplish. We need to review what security we need and > what is possible > > >to fit into this. I think we will have to face some hard > decisions before > > >the end of this work. Would a proxy really be able to > handle such a > > >message you propose. One bug I see is that the proxy > needs at least the > > >host part of the request URI to be able to send the > request to the correct > > >entity. And if you need trusted proxies, I think one > actually needs > > >consider that these proxies must be updated and security audited. > > > > > >I get the feeling that using TLS is rather simple but > requires a limited > > >usage model or trusted proxies. And as proxies can't > really be trusted, > > >what do we do? > > > > > > > > >Best Regards > > > > > >Magnus Westerlund > > >Multimedia Technologies, Ericsson Research ERA/TVA/A > > > >------------------------------------------------------------ > ---------- > > >Ericsson AB | Phone +46 8 4048287 > > >Torshamsgatan 23 | Fax +46 8 7575550 > > >S-164 80 Stockholm, Sweden | mailto: > magnus.westerlund@era.ericsson.se > > > > > > > > > > > >_______________________________________________ > > >mmusic mailing list > > >mmusic@ietf.org > > >https://www1.ietf.org/mailman/listinfo/mmusic > > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 07:46:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03776 for ; Fri, 25 Apr 2003 07:46:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PBnUV17727 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 07:49:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBnU817724 for ; Fri, 25 Apr 2003 07:49:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03745 for ; Fri, 25 Apr 2003 07:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1991ga-000712-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 07:48:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1991ga-00070z-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 07:48:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBnP817688; Fri, 25 Apr 2003 07:49:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PBkj817567 for ; Fri, 25 Apr 2003 07:46:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03579; Fri, 25 Apr 2003 07:43:11 -0400 (EDT) Message-Id: <200304251143.HAA03579@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 25 Apr 2003 07:43:10 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-offer-answer-examples-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Session Description Protocol Offer Answer Examples Author(s) : A. Johnston, R. Sparks Filename : draft-ietf-mmusic-offer-answer-examples-00.txt Pages : 24 Date : 2003-4-24 This document gives examples of Session Description Protocol (SDP) offer answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-examples-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-offer-answer-examples-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-4-24145552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-offer-answer-examples-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-offer-answer-examples-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-24145552.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 09:22:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07933 for ; Fri, 25 Apr 2003 09:22:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDQ5Y25438 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 09:26:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDQ5825435 for ; Fri, 25 Apr 2003 09:26:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07912 for ; Fri, 25 Apr 2003 09:22:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993BZ-0000Y8-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:24:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1993BZ-0000Y5-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:24:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDP7825297; Fri, 25 Apr 2003 09:25:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDOA825195 for ; Fri, 25 Apr 2003 09:24:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07841 for ; Fri, 25 Apr 2003 09:20:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993A2-0000Vr-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:22:42 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 1993A1-0000Vn-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:22:42 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3PDN9Mj034446; Fri, 25 Apr 2003 09:23:09 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304251323.h3PDN9Mj034446@purple.nge.isi.edu> To: Thomas Zeng cc: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? In-Reply-To: Your message of "Thu, 24 Apr 2003 18:39:02 PDT." <72263E8E8622D611975C0002B32C19D84A79F3@MISTY> Date: Fri, 25 Apr 2003 09:23:09 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --> Thomas Zeng writes: >Dear MMUSIC Mailing List: > >During last week's RTSP teleconference, we had a discussion on how to >distinguish the updated RTSP (i.e., the ongoing work >around draft-ietf-mmusic-rfc2326bis-03.txt, see >http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf). > >There is enough change on the table that we feel version number should be >increased to avoid confusion when RTSP server and client might be >implementing the old (rfc2326) and the new RTSP spec (will be a new RFC). Okay, that makes sense. >Should we increase the minor version to say RTSP/1.1, or should we up the >major version (to say RTSP/2.0)? If implementations of the two specifications can still interwork, albet with reduced functionality, then I'd go for RTSP/1.1. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 09:31:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08211 for ; Fri, 25 Apr 2003 09:31:45 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDYpj26025 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 09:34:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDYp826022 for ; Fri, 25 Apr 2003 09:34:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08185 for ; Fri, 25 Apr 2003 09:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993Jt-0000dN-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:32:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1993Jt-0000dK-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:32:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDY5825979; Fri, 25 Apr 2003 09:34:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDXP825916 for ; Fri, 25 Apr 2003 09:33:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08121 for ; Fri, 25 Apr 2003 09:29:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993Iv-0000bI-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:31:53 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1993Iv-0000bF-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:31:53 -0400 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3PDWL3o006359 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 25 Apr 2003 09:32:21 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3PDWGq1000944; Fri, 25 Apr 2003 09:32:17 -0400 (EDT) Message-ID: <3EA93818.5080505@cs.columbia.edu> Date: Fri, 25 Apr 2003 09:28:56 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: Thomas Zeng , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? References: <200304251323.h3PDN9Mj034446@purple.nge.isi.edu> In-Reply-To: <200304251323.h3PDN9Mj034446@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Unless there is a real and significant backwards-compatibility issue, I would strongly recommend against this. It gratuitously breaks existing implementations and greatly increases the deployment pain and confusion. Colin Perkins wrote: > --> Thomas Zeng writes: > >>Dear MMUSIC Mailing List: >> >>During last week's RTSP teleconference, we had a discussion on how to >>distinguish the updated RTSP (i.e., the ongoing work >>around draft-ietf-mmusic-rfc2326bis-03.txt, see >>http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf). >> >>There is enough change on the table that we feel version number should be >>increased to avoid confusion when RTSP server and client might be >>implementing the old (rfc2326) and the new RTSP spec (will be a new RFC). > > > Okay, that makes sense. > > >>Should we increase the minor version to say RTSP/1.1, or should we up the >>major version (to say RTSP/2.0)? > > > If implementations of the two specifications can still interwork, albet > with reduced functionality, then I'd go for RTSP/1.1. > > Colin > _______________________________________________ > 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 mailnull@www1.ietf.org Fri Apr 25 09:35:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08263 for ; Fri, 25 Apr 2003 09:35:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDclm27100 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 09:38:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDck827097 for ; Fri, 25 Apr 2003 09:38:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08254 for ; Fri, 25 Apr 2003 09:34:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993Nf-0000ee-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:36:47 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1993Nf-0000eb-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:36:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDc1827067; Fri, 25 Apr 2003 09:38:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDb1826240 for ; Fri, 25 Apr 2003 09:37:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08242 for ; Fri, 25 Apr 2003 09:33:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993MN-0000eL-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:35:27 -0400 Received: from dial162.east.isi.edu ([65.114.169.162] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 1993MM-0000eI-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:35:26 -0400 Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with ESMTP id h3PDZoMj034767; Fri, 25 Apr 2003 09:35:50 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200304251335.h3PDZoMj034767@purple.nge.isi.edu> To: Henning Schulzrinne cc: Thomas Zeng , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? In-Reply-To: Your message of "Fri, 25 Apr 2003 09:28:56 EDT." <3EA93818.5080505@cs.columbia.edu> Date: Fri, 25 Apr 2003 09:35:50 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , It may be less painful in the long run than a long list of supported features tags, etc. Colin --> Henning Schulzrinne writes: >Unless there is a real and significant backwards-compatibility issue, I >would strongly recommend against this. It gratuitously breaks existing >implementations and greatly increases the deployment pain and confusion. > >Colin Perkins wrote: >> --> Thomas Zeng writes: >> >>>Dear MMUSIC Mailing List: >>> >>>During last week's RTSP teleconference, we had a discussion on how to >>>distinguish the updated RTSP (i.e., the ongoing work >>>around draft-ietf-mmusic-rfc2326bis-03.txt, see >>>http://rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-rfc2326bis-03.pdf). >>> >>>There is enough change on the table that we feel version number should be >>>increased to avoid confusion when RTSP server and client might be >>>implementing the old (rfc2326) and the new RTSP spec (will be a new RFC). >> >> >> Okay, that makes sense. >> >> >>>Should we increase the minor version to say RTSP/1.1, or should we up the >>>major version (to say RTSP/2.0)? >> >> >> If implementations of the two specifications can still interwork, albet >> with reduced functionality, then I'd go for RTSP/1.1. >> >> Colin >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 09:42:45 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08447 for ; Fri, 25 Apr 2003 09:42:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PDjo627531 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 09:45:50 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDjo827528 for ; Fri, 25 Apr 2003 09:45:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08395 for ; Fri, 25 Apr 2003 09:41:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993Ua-0000i4-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:43:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1993Ua-0000i1-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 09:43:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDj7827480; Fri, 25 Apr 2003 09:45:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PDi0827401 for ; Fri, 25 Apr 2003 09:44:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08358 for ; Fri, 25 Apr 2003 09:40:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1993T6-0000gp-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:42:24 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1993T6-0000gm-00 for mmusic@ietf.org; Fri, 25 Apr 2003 09:42:24 -0400 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3PDgq3o006877 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 25 Apr 2003 09:42:52 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by opus.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id h3PDgpq1001377; Fri, 25 Apr 2003 09:42:51 -0400 (EDT) Message-ID: <3EA93A93.4030906@cs.columbia.edu> Date: Fri, 25 Apr 2003 09:39:31 -0400 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030401 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Perkins CC: Thomas Zeng , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? References: <200304251335.h3PDZoMj034767@purple.nge.isi.edu> In-Reply-To: <200304251335.h3PDZoMj034767@purple.nge.isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit To make a more informed communications, I would like to have a clear list of issues that would interfere with backward-compability. Colin Perkins wrote: > It may be less painful in the long run than a long list of supported > features tags, etc. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 14:40:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18474 for ; Fri, 25 Apr 2003 14:40:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PIhQO18637 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 14:43:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIhP818634 for ; Fri, 25 Apr 2003 14:43:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18447 for ; Fri, 25 Apr 2003 14:39:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19988z-0002mM-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 14:41:57 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19988y-0002mJ-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 14:41:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIh9818591; Fri, 25 Apr 2003 14:43:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIg9818550 for ; Fri, 25 Apr 2003 14:42:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18401 for ; Fri, 25 Apr 2003 14:38:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19987n-0002lg-00 for mmusic@ietf.org; Fri, 25 Apr 2003 14:40:43 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 19987m-0002la-00 for mmusic@ietf.org; Fri, 25 Apr 2003 14:40:42 -0400 Received: from RKUMAR-W2K.cisco.com (sjc-vpn3-89.cisco.com [10.21.64.89]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PIeb09005042; Fri, 25 Apr 2003 11:40:37 -0700 (PDT) Message-Id: <4.3.2.7.2.20030425113008.07426868@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Apr 2003 11:40:36 -0700 To: Colin Perkins From: Rajesh Kumar Cc: mmusic@ietf.org, flemming Andreasen , casner@acm.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com, rkumar@cisco.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1614110297==_.ALT" Subject: [MMUSIC] Multiple 'm' lines with the same port number Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --=====================_1614110297==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Colin, Steve, Is the use of multiple 'm=' lines with the same port number within an SDP descriptor permitted? In SDP, as it is defined, all the media formats on an 'm=' line are of the same media type (e.g. audio, image, text etc.). Now consider the case in which two RTP media formats can use a destination port but are registered under different MIME types. For example, text/t140 and audio/PCMU. In this case, there is no recourse except to use multiple media lines with the same port number. For example: m=audio 49232 RTP/AVP 0 m=text 49232 RTP/AVP 100 a=rtpmap:100 t140 My thought is that although this is unsual, it is not proscribed by SDP syntax in RFC 2327 or in its latest internet draft. Thanks, Rajesh --=====================_1614110297==_.ALT Content-Type: text/html; charset="us-ascii" Colin, Steve,
Is the use of multiple 'm=' lines with the same port number within an SDP descriptor permitted?

In SDP, as it is defined, all the media formats on an 'm=' line are of the same media type (e.g. audio, image, text etc.).

Now consider the case in which two RTP media formats can use a destination port but are registered under different MIME types. For example, text/t140 and audio/PCMU. In this case, there is no recourse except to use multiple media lines with the same port number. For example:

m=audio 49232 RTP/AVP 0
m=text 49232 RTP/AVP 100
a=rtpmap:100 t140

My thought is that although this is unsual, it is not proscribed by SDP syntax in RFC 2327 or in its latest internet draft.

Thanks,

Rajesh

 --=====================_1614110297==_.ALT-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 14:57:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19042 for ; Fri, 25 Apr 2003 14:57:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PJ0Rg19275 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 15:00:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJ0R819272 for ; Fri, 25 Apr 2003 15:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19034 for ; Fri, 25 Apr 2003 14:56:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1998PS-0002uc-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 14:58:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1998PR-0002uZ-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 14:58:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJ08819257; Fri, 25 Apr 2003 15:00:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PIx7819184 for ; Fri, 25 Apr 2003 14:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18987 for ; Fri, 25 Apr 2003 14:55:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1998OD-0002uP-00 for mmusic@ietf.org; Fri, 25 Apr 2003 14:57:41 -0400 Received: from www.route-explorer.net ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1998OC-0002u4-00 for mmusic@ietf.org; Fri, 25 Apr 2003 14:57:40 -0400 Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id h3PIvNvW072738; Fri, 25 Apr 2003 11:57:23 -0700 (PDT) (envelope-from casner@acm.org) Date: Fri, 25 Apr 2003 11:57:23 -0700 (PDT) From: Stephen Casner To: Rajesh Kumar cc: Colin Perkins , , flemming Andreasen , , , , In-Reply-To: <4.3.2.7.2.20030425113008.07426868@mira-sjc5-8.cisco.com> Message-ID: <20030425114849.X77830-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Rajesh, > Is the use of multiple 'm=' lines with the same port number within an SDP > descriptor permitted? Presuming that the multiple m= lines are all RTP/AVP, then doing so causes all of the payload formats listed on the m= lines to become part of a single RTP session (unless they are distinguished by some other aspect of addressing). Section 5.2 of the RTP spec addresses NOT multiplexing different media in the same RTP session. > In SDP, as it is defined, all the media formats on an 'm=' line are of the > same media type (e.g. audio, image, text etc.). > > Now consider the case in which two RTP media formats can use a destination > port but are registered under different MIME types. For example, text/t140 > and audio/PCMU. In this case, there is no recourse except to use multiple > media lines with the same port number. For example: The "can use a destination port" is the tricky part. We may not agree. > m=audio 49232 RTP/AVP 0 > m=text 49232 RTP/AVP 100 > a=rtpmap:100 t140 > > My thought is that although this is unsual, it is not proscribed by SDP > syntax in RFC 2327 or in its latest internet draft. I believe this is proscribed by section 5.2 of the RTP spec because these two media should not be multiplexed in one RTP session. My bet is that the real example you are thinking about is fax or modem over IP. We've been there before. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 16:31:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21920 for ; Fri, 25 Apr 2003 16:31:38 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKYsf25993 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 16:34:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKYr825990 for ; Fri, 25 Apr 2003 16:34:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21877 for ; Fri, 25 Apr 2003 16:31:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999so-0003UE-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 16:33:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1999so-0003UB-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 16:33:22 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKYV825963; Fri, 25 Apr 2003 16:34:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKWk825771 for ; Fri, 25 Apr 2003 16:32:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21707 for ; Fri, 25 Apr 2003 16:29:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999qn-0003Rc-00 for mmusic@ietf.org; Fri, 25 Apr 2003 16:31:17 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by ietf-mx with esmtp (Exim 4.12) id 1999qn-0003RJ-00 for mmusic@ietf.org; Fri, 25 Apr 2003 16:31:17 -0400 Received: from RKUMAR-W2K.cisco.com (sjc-vpn3-89.cisco.com [10.21.64.89]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h3PKG3IE008986; Fri, 25 Apr 2003 13:16:04 -0700 (PDT) Message-Id: <4.3.2.7.2.20030425130756.074b96a0@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Apr 2003 13:16:03 -0700 To: Stephen Casner From: Rajesh Kumar Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Cc: Colin Perkins , , flemming Andreasen , , , , In-Reply-To: <20030425114849.X77830-100000@ash.packetdesign.com> References: <4.3.2.7.2.20030425113008.07426868@mira-sjc5-8.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1619836802==_.ALT" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --=====================_1619836802==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Steve, The real examples I am thinking of are all RTP-encapsulated payloads such as text/t140 and the new t38-facsimile-over-RTP work that I am involved in with Mario Garakani and Paul Jones and others. In all these cases, the payload is encaspulated in RTP and uses the RTP/AVP profile. So this is not a repeat of an old issue. So if facsimile were encapsulated in RTP, you would need a new MIME audio/t38 to multiplex it with PCMU into the same UDP port? The current MIME for T.38 facsimile over IP is image/t38. Or does the standard proscribe the multiplexing into a single port of PCMU and RTP-encapsulate-facsimile altogether? I do not think so. Thanks, Rajesh At 11:57 AM 4/25/2003 -0700, Stephen Casner wrote: >Rajesh, > > > Is the use of multiple 'm=' lines with the same port number within an SDP > > descriptor permitted? > >Presuming that the multiple m= lines are all RTP/AVP, then doing so >causes all of the payload formats listed on the m= lines to become >part of a single RTP session (unless they are distinguished by some >other aspect of addressing). Section 5.2 of the RTP spec addresses >NOT multiplexing different media in the same RTP session. > > > In SDP, as it is defined, all the media formats on an 'm=' line are of the > > same media type (e.g. audio, image, text etc.). > > > > Now consider the case in which two RTP media formats can use a destination > > port but are registered under different MIME types. For example, text/t140 > > and audio/PCMU. In this case, there is no recourse except to use multiple > > media lines with the same port number. For example: > >The "can use a destination port" is the tricky part. We may not agree. > > > m=audio 49232 RTP/AVP 0 > > m=text 49232 RTP/AVP 100 > > a=rtpmap:100 t140 > > > > My thought is that although this is unsual, it is not proscribed by SDP > > syntax in RFC 2327 or in its latest internet draft. > >I believe this is proscribed by section 5.2 of the RTP spec because >these two media should not be multiplexed in one RTP session. > >My bet is that the real example you are thinking about is fax or modem >over IP. We've been there before. > > -- Steve > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic --=====================_1619836802==_.ALT Content-Type: text/html; charset="us-ascii" Steve,
The real examples I am thinking of are all RTP-encapsulated payloads such as text/t140 and the new t38-facsimile-over-RTP work that I am involved in with Mario Garakani and Paul Jones and others. In all these cases, the payload is encaspulated in RTP and uses the RTP/AVP profile. So this is not a repeat of an old issue. 

So if facsimile were encapsulated in RTP, you would need a new MIME audio/t38 to multiplex it with PCMU into the same UDP port? The current MIME for T.38 facsimile over IP is image/t38. Or does the standard proscribe the multiplexing into a single port of  PCMU and RTP-encapsulate-facsimile altogether? I do not think so.

Thanks,

Rajesh

At 11:57 AM 4/25/2003 -0700, Stephen Casner wrote:
Rajesh,

> Is the use of multiple 'm=' lines with the same port number within an SDP
> descriptor permitted?

Presuming that the multiple m= lines are all RTP/AVP, then doing so
causes all of the payload formats listed on the m= lines to become
part of a single RTP session (unless they are distinguished by some
other aspect of addressing).  Section 5.2 of the RTP spec addresses
NOT multiplexing different media in the same RTP session.

> In SDP, as it is defined, all the media formats on an 'm=' line are of the
> same media type (e.g. audio, image, text etc.).
>
> Now consider the case in which two RTP media formats can use a destination
> port but are registered under different MIME types. For example, text/t140
> and audio/PCMU. In this case, there is no recourse except to use multiple
> media lines with the same port number. For example:

The "can use a destination port" is the tricky part.  We may not agree.

> m=audio 49232 RTP/AVP 0
> m=text 49232 RTP/AVP 100
> a=rtpmap:100 t140
>
> My thought is that although this is unsual, it is not proscribed by SDP
> syntax in RFC 2327 or in its latest internet draft.

I believe this is proscribed by section 5.2 of the RTP spec because
these two media should not be multiplexed in one RTP session.

My bet is that the real example you are thinking about is fax or modem
over IP.  We've been there before.

                                                        -- Steve

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic
--=====================_1619836802==_.ALT-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 16:54:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23230 for ; Fri, 25 Apr 2003 16:54:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKvIS27995 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 16:57:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKvH827992 for ; Fri, 25 Apr 2003 16:57:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23224 for ; Fri, 25 Apr 2003 16:53:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199AEW-0003b4-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 16:55:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 199AEV-0003b1-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 16:55:47 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKv4827980; Fri, 25 Apr 2003 16:57:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKuC827943 for ; Fri, 25 Apr 2003 16:56:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23213 for ; Fri, 25 Apr 2003 16:52:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199ADT-0003al-00 for mmusic@ietf.org; Fri, 25 Apr 2003 16:54:43 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by ietf-mx with esmtp (Exim 4.12) id 199ADT-0003ad-00 for mmusic@ietf.org; Fri, 25 Apr 2003 16:54:43 -0400 Received: from cisco.com (sjc-vpn4-450.cisco.com [10.21.81.194]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h3PKdd08029980; Fri, 25 Apr 2003 13:39:40 -0700 (PDT) Message-ID: <3EA99D0B.E44A6EF3@cisco.com> Date: Fri, 25 Apr 2003 16:39:39 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Casner CC: Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <20030425114849.X77830-100000@ash.packetdesign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Stephen Casner wrote: > Rajesh, > > > Is the use of multiple 'm=' lines with the same port number within an SDP > > descriptor permitted? > > Presuming that the multiple m= lines are all RTP/AVP, then doing so > causes all of the payload formats listed on the m= lines to become > part of a single RTP session (unless they are distinguished by some > other aspect of addressing). Section 5.2 of the RTP spec addresses > NOT multiplexing different media in the same RTP session. > > > In SDP, as it is defined, all the media formats on an 'm=' line are of the > > same media type (e.g. audio, image, text etc.). > > > > Now consider the case in which two RTP media formats can use a destination > > port but are registered under different MIME types. For example, text/t140 > > and audio/PCMU. In this case, there is no recourse except to use multiple > > media lines with the same port number. For example: > > The "can use a destination port" is the tricky part. We may not agree. > We also seem to be entering a bit of a gray area here in terms of offer/answer (RFC 3264). It's not clear that the definition of "m=" lines and media streams allow for something like this; for sure the parties would have to recognize that the two "m=" lines in fact are one media stream and hence should not be sending to "both" at the same time. However, I'm not aware of such behavior being specified anywhere. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Fri Apr 25 22:07:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29621 for ; Fri, 25 Apr 2003 22:07:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3Q2BAG15825 for mmusic-archive@odin.ietf.org; Fri, 25 Apr 2003 22:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2BA815822 for ; Fri, 25 Apr 2003 22:11:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29613 for ; Fri, 25 Apr 2003 22:07:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199F87-0004vi-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 22:09:31 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 199F87-0004ve-00 for mmusic-web-archive@ietf.org; Fri, 25 Apr 2003 22:09:31 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q2Am815786; Fri, 25 Apr 2003 22:10:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3Q29M815719 for ; Fri, 25 Apr 2003 22:09:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29573 for ; Fri, 25 Apr 2003 22:05:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 199F6R-0004uu-00 for mmusic@ietf.org; Fri, 25 Apr 2003 22:07:47 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 199F6Q-0004uX-00 for mmusic@ietf.org; Fri, 25 Apr 2003 22:07:46 -0400 Received: from [192.168.104.21] ([::ffff:12.212.102.143]) (AUTH: LOGIN robla, ) by flawless.real.com with esmtp; Fri, 25 Apr 2003 19:07:40 -0700 Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? From: Rob Lanphier To: Henning Schulzrinne Cc: Colin Perkins , Thomas Zeng , "'mmusic@ietf.org'" In-Reply-To: <3EA93A93.4030906@cs.columbia.edu> References: <200304251335.h3PDZoMj034767@purple.nge.isi.edu> <3EA93A93.4030906@cs.columbia.edu> Message-Id: <1051323029.31809.5.camel@dhcppc4> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.2.0 Date: 25 Apr 2003 19:10:29 -0700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Read the draft. You are a co-author after all ;-) Rob On Fri, 2003-04-25 at 06:39, Henning Schulzrinne wrote: > To make a more informed communications, I would like to have a clear > list of issues that would interfere with backward-compability. > > Colin Perkins wrote: > > > It may be less painful in the long run than a long list of supported > > features tags, etc. > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Rob Lanphier, Helix Community Coordinator - RealNetworks http://helixcommunity.org http://rtsp.org http://realnetworks.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 28 03:41:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23147 for ; Mon, 28 Apr 2003 03:41:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3S7jc816158 for mmusic-archive@odin.ietf.org; Mon, 28 Apr 2003 03:45:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7jb816155 for ; Mon, 28 Apr 2003 03:45:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23137 for ; Mon, 28 Apr 2003 03:40:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A3Hp-00017n-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 03:42:53 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19A3Ho-00017j-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 03:42:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7jQ816124; Mon, 28 Apr 2003 03:45:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3S7hb816036 for ; Mon, 28 Apr 2003 03:43:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23106 for ; Mon, 28 Apr 2003 03:38:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19A3Fk-000170-00 for mmusic@ietf.org; Mon, 28 Apr 2003 03:40:44 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19A3FP-00016n-00 for mmusic@ietf.org; Mon, 28 Apr 2003 03:40:24 -0400 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3S7ecI3029297; Mon, 28 Apr 2003 09:40:38 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id JZWWRKM4; Mon, 28 Apr 2003 09:40:38 +0200 Message-ID: <3EACDAB3.1040300@era.ericsson.se> Date: Mon, 28 Apr 2003 09:39:31 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: "'mmusic@ietf.org'" Subject: Re: [MMUSIC] How to identify the updated RTSP specification ? References: <200304251335.h3PDZoMj034767@purple.nge.isi.edu> <3EA93A93.4030906@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Henning, The major incompatibilities are: 1. State machine change. A old client that want to play a media again after reaching the end of the media may not be able to restart. 2. Transport header changes: - Defined extensible - New source and destination header types that handle lists and IPv6 addresses Plus all the small things that really are quite a number of. Depending on the use case you might be able to avoid most of them. The three options available to us in this question are: 1. Stay with version 1.0 and use feature tags to allow clients and server to know that the other party supports the functionality. Feature tags will still be need within a version to detect functionality support. 2. Go to version 1.1, i.e. a minor version upgrade. By looking into RFC 2616 and RFC 2145 the accepted changes shall not effect the general parsing mechanism. And from RFC 2145 the following quote can be made: It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header does not change between minor versions of the same major version. Another interesting quote is: One consequence of these rules is that an HTTP/1.1 message sent to an HTTP/1.0 recipient (or a recipient whose version is unknown) MUST be constructed so that it remains a valid HTTP/1.0 message when all headers not defined in the HTTP/1.0 specification [1] are removed. 3. Change the major version number, i.e. version 2.0. The big questions to consider is: - What effect on deployment will a change of the version number? - What is acceptable from the protocol side? To the second question the quotes seems to indicate that we would be forced to a version 2.0 for what we have done. We have after all changed a rather large number of header syntax's. I don't know it this is a good thing for deployment. More input into this question is encouraged. Best Regards Magnus Henning Schulzrinne wrote: > To make a more informed communications, I would like to have a clear > list of issues that would interfere with backward-compability. > > Colin Perkins wrote: > >> It may be less painful in the long run than a long list of supported >> features tags, etc. > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 28 11:18:39 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04182 for ; Mon, 28 Apr 2003 11:18:39 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SFNFa18196 for mmusic-archive@odin.ietf.org; Mon, 28 Apr 2003 11:23:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFNF818193 for ; Mon, 28 Apr 2003 11:23:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04173 for ; Mon, 28 Apr 2003 11:18:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AAQY-0003QQ-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 11:20:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AAQX-0003QL-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 11:20:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFLM818125; Mon, 28 Apr 2003 11:21:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFKI818098 for ; Mon, 28 Apr 2003 11:20:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04105 for ; Mon, 28 Apr 2003 11:15:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AANh-0003Pu-00 for mmusic@ietf.org; Mon, 28 Apr 2003 11:17:25 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19AANg-0003Pf-00 for mmusic@ietf.org; Mon, 28 Apr 2003 11:17:25 -0400 Received: from ha2mpk-mail.Eng.Sun.COM ([129.146.16.22]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA12526 for ; Mon, 28 Apr 2003 08:17:29 -0700 (PDT) Received: from sun.com (vpn-129-150-16-229.SFBay.Sun.COM [129.150.16.229]) by ha2mpk-mail.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA08140 for ; Mon, 28 Apr 2003 08:17:28 -0700 (PDT) Message-ID: <3EAD45C9.2090809@sun.com> Date: Mon, 28 Apr 2003 11:16:25 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 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 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Clarification of Re-Setup handling in RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hey Folks, I have come up with the proposed wording for the resolution of bug 513737 (http://rtsp.org/bug513737). First let me cite the resolution that was reached in conference call on March 5th: Resolution: go with alternative #1 from bug report (1. Keep the old setting and states as if the second SETUP never happend.) Here my attempt to clarify the wording in the spec according to the resolution of the concall: Wording from draft-ietf-mmusic-rfc2326bis-03.txt 11.3 SETUP The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a SETUP request for a stream that is already set up or playing in the session to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error 455 (Method Not Valid In This State). A server MAY allow a client to do SETUP while in playing state to add additional media streams. If not supported the server shall responde with error 455 (Method Not Allowed In This State). If supported the added media shall then start to play in sync with the already playing media. To be able to sync the media with the already playing streams the SETUP response MUST include a RTP-Info header with the timestamp value, and a Range header with the corresponding normal play time. To indicate support for this optional feature the feature-tag: "setup.playing" is defined. New proposed wording: 11.3 SETUP The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a SETUP request for a stream that is already set up or playing in the session to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error 455 (Method Not Valid In This State). A server MAY allow a client to do SETUP while in playing state to add additional media streams. If not supported, the server shall respond | with error 455 (Method Not Valid in This State). If supported the | added media shall then start to play in sync with the already playing media. To be able to sync the media with the already playing streams the SETUP response MUST include a RTP-Info header with the timestamp value, and a Range header with the corresponding normal play time. To indicate support for this optional feature the feature-tag: "setup.playing" is defined. If a SETUP request on a session fails for any reason, the session | state, as well as transport and other parameters for associated | streams will remain unchanged from their values as if the SETUP | request had never been received by the server. | Please send your comments. Thanks Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 28 12:06:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05678 for ; Mon, 28 Apr 2003 12:06:42 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SGBJH22530 for mmusic-archive@odin.ietf.org; Mon, 28 Apr 2003 12:11:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SGBJ822527 for ; Mon, 28 Apr 2003 12:11:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05667 for ; Mon, 28 Apr 2003 12:06:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ABB3-0003hW-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 12:08:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ABB2-0003hT-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 12:08:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SG9Q822480; Mon, 28 Apr 2003 12:09:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SG0G820772 for ; Mon, 28 Apr 2003 12:00:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05376 for ; Mon, 28 Apr 2003 11:55:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AB0L-0003e1-00 for mmusic@ietf.org; Mon, 28 Apr 2003 11:57:22 -0400 Received: from pheriche.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19AB0L-0003dy-00 for mmusic@ietf.org; Mon, 28 Apr 2003 11:57:21 -0400 Received: from ha2mpk-mail.Eng.Sun.COM ([129.146.16.22]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA25361; Mon, 28 Apr 2003 09:57:55 -0600 (MDT) Received: from sun.com (vpn-129-150-16-229.SFBay.Sun.COM [129.150.16.229]) by ha2mpk-mail.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA19815; Mon, 28 Apr 2003 08:57:54 -0700 (PDT) Message-ID: <3EAD4F42.60001@sun.com> Date: Mon, 28 Apr 2003 11:56:50 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Magnus Westerlund CC: mmusic@ietf.org Subject: Re: [MMUSIC] Backwards range and negative scale clarification (bugs 533691, 513880) References: <3E9D7CE9.1010004@sun.com> <3EA68215.4090709@era.ericsson.se> In-Reply-To: <3EA68215.4090709@era.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hey Magnus, Thanks for the excellent summary of our concall. Another potential way to resolve the situation with the closed/openeness of ranges headers that we haven't discussed before is to include another field, "type=" (similar to the "time=" field) in the range header which explicitly defines the exact nature of the range header. For example: PLAY rtsp://foo RTSP/1.0 Session: bar Range: ntp=5-10; type=1 where we have a predefined set of types: 0 = default RFC 2326 behavior 1 = closed on both ends 2 = open on both ends 3 = start open, end closed Obviously, we dont need to specify more types than absolutely necessary. Now if the type is not specified in a play request, we can specify that the default behavior as specified in RFC 2326 with halfopen interval will be followed. However, for more precise handling of the Range, the type would have to be specified.. . I think this is a good compromise without having to make corner cases as is option A below, or changing the semantic of Range completely as in option C below. more comments inline: Magnus Westerlund wrote: > Hi, > > This was discussed at the last telecon. There was no conclusions on > how to solve it. There where three proposals. I also give some of my > personal views on the matter. > > A. Make an exception at 0. So that any half open end point that > includes 0 actually is closed at 0. The only real problem with having > a open end interval when playing backwards is the end point a 0, as we > can't give negative numbers in npt scale. One can of course leave the > interval without a second value. However if a server in a response > would like to tell that it is playing to 0 it is still not good. > > > B. Make the range header interpretation depend on scale header sign. > For negative scale the range header would go from a open to a closed > point. Example Range: Scale=-1 npt=10-5 would mean: play from just > before 10 to and including 5. However I see some problem with trying > to start playback with an open interval. Where is the differnece > between a point and very, very close to it. Also how does one handle > RTP-Info if the synchronization point is not defined. I dont think that the RTP-Info causes a problem. The RTP-Info is returned for the actual range this is going to be played back. This range needs to go in PLAY response and that RTP-Info will then correspond to that range start time. > C. Make the Range header interval closed in both ends. The argument > was that we don't need the distinction provided by an half open > interval and by closing it in both ends one forces the server to play > the whole given interval and the client trims any excess. There are > some backwards considerations in this case. > > > To the second issue: I think there is reasons to play media with real > time scale backwards. My favourite example is the Surveilance video > storage server. This media is of course indexed using real world > clock. So if you desire to view the surveilance tape backwards then > you need it. Ok I can kind of buy this argument. However, I think it is important to call this out in the spec. or in an appendix to the spec, because I'm sure it will be many people's first assumption to assume that time cannot travel backwards. > > Any more comments? > > Best Regards > > Magnus > > > Aravind Narasimhan wrote: > >> Hi Folks, In my attempt to clarify the negative scale and >> backwards range issues brought up by bugs http://rtsp.org/bug533691 >> & http://rtsp.org/bug513880 some issues surfaced with regards to the >> current definition of ranges in the spec. I wanted to discuss these >> issues before sending off my write up. >> >> Issue 1: >> --------- >> Range is defined in RTSP as a half open interval. To quote from >> draft-03 >> >> Ranges are half-open intervals, including the lower point, but >> excluding the upper point. In other words, a range of a-b starts >> exactly at time a, but stops just before b. >> >> Now the resolution that we came up with for this issue was that we >> would always go from the first number in the range to the last number >> in the range. So for example, if the range of a PLAY request was >> Range: npt=10-15 >> we would go from 10 -> 15, where the play would stop just before 15. >> If the request had range and scale headers as the following: >> Scale: -1 >> Range: npt=15-10 >> the play would go backwards and we would go from 15 -> 10. >> >> Now the question is how do we interpret the half-open rule. I.e. Do >> we stop at 10 or just before we reach 10 (i.e. npt > 10) in the >> backwards scenario above? The latter seems like they way to interpret >> the half - open rule. But if we interpret it that way, then how do >> we deal with the following: >> Scale: -1 >> Range: npt=15-0 >> We would have to stop before 0 and there would be no way to get to 0 >> since you cannot specify negative ranges. Obviously the way to get >> around this is to do the following: >> Scale: -1 >> Range: npt=15- >> But this doesn't seem too clean to me. >> >> The other option is to say that backwards ranges are always closed >> ranges. This, however, makes ranges a bit more inconsisted and >> harder to deal with. >> >> Issue 2: >> ---------- >> The other thing that doesn't make sense with backwards ranges are the >> Clock ranges. For example: >> Scale: -1 >> Range: clock=20030416T000000.00Z-20030101T000000.00Z >> makes no sense because clocks cant go backwards. >> >> So I propose that Scale can only be negative for ranges that deal >> with relative time rather than absolute time. >> >> > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 28 17:30:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15033 for ; Mon, 28 Apr 2003 17:30:46 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SLZVI16021 for mmusic-archive@odin.ietf.org; Mon, 28 Apr 2003 17:35:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SLZV816018 for ; Mon, 28 Apr 2003 17:35:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15026 for ; Mon, 28 Apr 2003 17:30:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AGEg-0005YA-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 17:32:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AGEg-0005Y7-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 17:32:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SLZD815979; Mon, 28 Apr 2003 17:35:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SLYJ815940 for ; Mon, 28 Apr 2003 17:34:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14997; Mon, 28 Apr 2003 17:29:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AGDW-0005XR-00; Mon, 28 Apr 2003 17:31:18 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19AGDV-0005XM-00; Mon, 28 Apr 2003 17:31:17 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3SLVq026907; Mon, 28 Apr 2003 14:31:52 -0700 (PDT) Message-Id: <200304282131.h3SLVq026907@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, mmusic@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 28 Apr 2003 14:31:52 -0700 Subject: [MMUSIC] RFC 3524 on Mapping of Media Streams to Resource Reservation Flows Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3324 Title: Mapping of Media Streams to Resource Reservation Flows Author(s): G. Camarillo, A. Monrad Status: Standards Track Date: April 2003 Mailbox: Gonzalo.Camarillo@ericsson.com, atle.monrad@ericsson.com Pages: 6 Characters: 11249 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-reservation-flows-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3524.txt This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030428143025.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3524 --OtherAccess Content-Type: Message/External-body; name="rfc3524.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030428143025.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Mon Apr 28 23:41:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23671 for ; Mon, 28 Apr 2003 23:41:41 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3T3kX312810 for mmusic-archive@odin.ietf.org; Mon, 28 Apr 2003 23:46:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3kX812807 for ; Mon, 28 Apr 2003 23:46:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23664 for ; Mon, 28 Apr 2003 23:41:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AM1c-0007Ua-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 23:43:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AM1c-0007UX-00 for mmusic-web-archive@ietf.org; Mon, 28 Apr 2003 23:43:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3kQ812799; Mon, 28 Apr 2003 23:46:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3T3jf812758 for ; Mon, 28 Apr 2003 23:45:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23635 for ; Mon, 28 Apr 2003 23:40:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AM0m-0007UG-00 for mmusic@ietf.org; Mon, 28 Apr 2003 23:42:32 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19AM0m-0007UC-00 for mmusic@ietf.org; Mon, 28 Apr 2003 23:42:32 -0400 Received: from dynamicsoft.com ([63.113.46.76]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3T3gVdh003761; Mon, 28 Apr 2003 23:42:32 -0400 (EDT) Message-ID: <3EADB4FD.3090303@dynamicsoft.com> Date: Mon, 28 Apr 2003 19:10:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen CC: Stephen Casner , Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <20030425114849.X77830-100000@ash.packetdesign.com> <3EA99D0B.E44A6EF3@cisco.com> In-Reply-To: <3EA99D0B.E44A6EF3@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit inline. Flemming Andreasen wrote: > > Stephen Casner wrote: > > >>Rajesh, >> >> >>>Is the use of multiple 'm=' lines with the same port number within an SDP >>>descriptor permitted? >> >>Presuming that the multiple m= lines are all RTP/AVP, then doing so >>causes all of the payload formats listed on the m= lines to become >>part of a single RTP session (unless they are distinguished by some >>other aspect of addressing). Section 5.2 of the RTP spec addresses >>NOT multiplexing different media in the same RTP session. >> >> >>>In SDP, as it is defined, all the media formats on an 'm=' line are of the >>>same media type (e.g. audio, image, text etc.). >>> >>>Now consider the case in which two RTP media formats can use a destination >>>port but are registered under different MIME types. For example, text/t140 >>>and audio/PCMU. In this case, there is no recourse except to use multiple >>>media lines with the same port number. For example: >> >>The "can use a destination port" is the tricky part. We may not agree. >> > > > We also seem to be entering a bit of a gray area here in terms of offer/answer > (RFC 3264). It's not clear that the definition of "m=" lines and media streams > allow for something like this; for sure the parties would have to recognize that > the two "m=" lines in fact are one media stream and hence should not be sending > to "both" at the same time. However, I'm not aware of such behavior being > specified anywhere. Using two m lines to represent alternate encodings for a stream is not consistent with the offer/answer model, IMHO. RFC 3264 has mechanisms for transitioning from audio to fax, for example, but these require a re-invite to do: 8.3.3 Changing Media Types The media type (audio, video, etc.) for a stream MAY be changed. It is RECOMMENDED that the media type be changed (as opposed to adding a new stream), when the same logical data is being conveyed, but just in a different media format. This is particularly useful for changing between voiceband fax and fax in a single stream, which are both separate media types. To do this, the offerer creates a new media description, with a new media type, in place of the description in the previous SDP which is to be changed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 29 10:50:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25955 for ; Tue, 29 Apr 2003 10:50:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TEteK18358 for mmusic-archive@odin.ietf.org; Tue, 29 Apr 2003 10:55:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEte818355 for ; Tue, 29 Apr 2003 10:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25914 for ; Tue, 29 Apr 2003 10:50:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AWSv-0004wF-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 10:52:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AWSu-0004wB-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 10:52:16 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEtS818342; Tue, 29 Apr 2003 10:55:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TEsI818293 for ; Tue, 29 Apr 2003 10:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25735; Tue, 29 Apr 2003 10:48:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AWRa-0004sH-00; Tue, 29 Apr 2003 10:50:54 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19AWRZ-0004rr-00; Tue, 29 Apr 2003 10:50:53 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h3TEpT010888; Tue, 29 Apr 2003 07:51:29 -0700 (PDT) Message-Id: <200304291451.h3TEpT010888@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, mmusic@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 29 Apr 2003 07:51:28 -0700 Subject: [MMUSIC] Correction: RFC 3524 on Mapping of Media Streams to Resource Reservation Flows Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3524 Title: Mapping of Media Streams to Resource Reservation Flows Author(s): G. Camarillo, A. Monrad Status: Standards Track Date: April 2003 Mailbox: Gonzalo.Camarillo@ericsson.com, atle.monrad@ericsson.com Pages: 6 Characters: 11249 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-reservation-flows-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3524.txt This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF). This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030429074856.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3524 --OtherAccess Content-Type: Message/External-body; name="rfc3524.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030429074856.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 29 12:58:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01313 for ; Tue, 29 Apr 2003 12:58:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TH3SF32133 for mmusic-archive@odin.ietf.org; Tue, 29 Apr 2003 13:03:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TH3S832130 for ; Tue, 29 Apr 2003 13:03:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01287 for ; Tue, 29 Apr 2003 12:57:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AYSY-00067d-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 13:00:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AYSX-00067a-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 13:00:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TH3D832098; Tue, 29 Apr 2003 13:03:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TH04830801 for ; Tue, 29 Apr 2003 13:00:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01143 for ; Tue, 29 Apr 2003 12:54:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AYPG-00065d-00 for mmusic@ietf.org; Tue, 29 Apr 2003 12:56:38 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19AYPG-00065M-00 for mmusic@ietf.org; Tue, 29 Apr 2003 12:56:38 -0400 Received: from raven.dev.prognet.com ([::ffff:172.22.22.16]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Tue, 29 Apr 2003 09:56:41 -0700 Date: Tue, 29 Apr 2003 10:00:54 -0700 (PDT) From: Aaron Colwell To: mmusic@ietf.org Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I have a few questions about section 3.2.3 list item 8. It says "For RTCP it starts transmitting RTCP packets according to the rules." 1. Does this mean that it starts sending compound SR and SDES packets? 2. Is the client supposed to created it's own CNAME for this stream of packets or does the CNAME need to be sent from the server to the client? 3. Should the client and server both send RR info to eachother about the RTP packets they are sending? 4. Are there any requirements for the RTP packet timestamps other than being monotonically increasing? Aaron _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 29 14:04:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03975 for ; Tue, 29 Apr 2003 14:04:36 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TI9ja07177 for mmusic-archive@odin.ietf.org; Tue, 29 Apr 2003 14:09:45 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TI9j807174 for ; Tue, 29 Apr 2003 14:09:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03958 for ; Tue, 29 Apr 2003 14:04:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZUg-0006h5-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 14:06:18 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AZUf-0006h2-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 14:06:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TI9c807166; Tue, 29 Apr 2003 14:09:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TI8I807093 for ; Tue, 29 Apr 2003 14:08:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03846 for ; Tue, 29 Apr 2003 14:02:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AZTH-0006fj-00 for mmusic@ietf.org; Tue, 29 Apr 2003 14:04:51 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19AZTG-0006fg-00 for mmusic@ietf.org; Tue, 29 Apr 2003 14:04:50 -0400 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3TI5RRs021131; Tue, 29 Apr 2003 20:05:27 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id J727T4C0; Tue, 29 Apr 2003 20:05:26 +0200 Message-ID: <3EAEBEA0.7070700@era.ericsson.se> Date: Tue, 29 Apr 2003 20:04:16 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell , IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aaron, See my answer below inline. Aaron Colwell wrote: >I have a few questions about section 3.2.3 list item 8. It says >"For RTCP it starts transmitting RTCP packets according to the rules." > >1. Does this mean that it starts sending compound SR and SDES packets? > Depends on the RTP session state. Unless the server has not sent any RTP packets yet it must send RR and SDES. If it has sent RTP packets then it need to send SR and SDES. >2. Is the client supposed to created it's own CNAME for this stream of > packets or does the CNAME need to be sent from the server to the client? > The client must set a CNAME of its own. That it must always do when sending RTCP in a RTP session. >3. Should the client and server both send RR info to eachother about the > RTP packets they are sending? > Yes, It should report on these packets. >4. Are there any requirements for the RTP packet timestamps other than > being monotonically increasing? > No, I need to think over what would be the best strategy here. One would be to use the RTP send time as TS basis. In general I think we need to further look over this section. Is it a good thing to use PT=0, i.e. PCM audio with no samples for these packets? Please comment. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 29 17:24:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11296 for ; Tue, 29 Apr 2003 17:24:58 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TLUD525632 for mmusic-archive@odin.ietf.org; Tue, 29 Apr 2003 17:30:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLUC825629 for ; Tue, 29 Apr 2003 17:30:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11211 for ; Tue, 29 Apr 2003 17:24:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Accb-0000Ku-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 17:26:41 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Acca-0000Kr-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 17:26:40 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLTV825562; Tue, 29 Apr 2003 17:29:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLS5825479 for ; Tue, 29 Apr 2003 17:28:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11088 for ; Tue, 29 Apr 2003 17:22:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AcaY-0000I4-00 for mmusic@ietf.org; Tue, 29 Apr 2003 17:24:34 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 19AcaX-0000Hi-00 for mmusic@ietf.org; Tue, 29 Apr 2003 17:24:33 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.9/8.12.9) with ESMTP id h3TLOYqq090420; Tue, 29 Apr 2003 14:24:34 -0700 (PDT) Received: by MISTY with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Apr 2003 14:24:34 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D84A7A1F@MISTY> From: Thomas Zeng To: "'Magnus Westerlund'" , Aaron Colwell , IETF MMUSIC WG Subject: RE: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Date: Tue, 29 Apr 2003 14:24:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] > > Sent: Tuesday, April 29, 2003 11:04 AM > To: Aaron Colwell; IETF MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions > > Hi Aaron, > > See my answer below inline. > > Aaron Colwell wrote: > > >I have a few questions about section 3.2.3 list item 8. It says > >"For RTCP it starts transmitting RTCP packets according to the rules." > > > >1. Does this mean that it starts sending compound SR and SDES packets? > > > > Depends on the RTP session state. Unless the server has not sent any RTP > packets yet it must send RR and SDES. If it has sent RTP packets then it > need to send SR and SDES. > > >2. Is the client supposed to created it's own CNAME for this stream of > > packets or does the CNAME need to be sent from the server to the > client? > > > The client must set a CNAME of its own. That it must always do when > sending RTCP in a RTP session. > > >3. Should the client and server both send RR info to eachother about the > > RTP packets they are sending? > > > > Yes, It should report on these packets. > > >4. Are there any requirements for the RTP packet timestamps other than > > being monotonically increasing? > > > > No, I need to think over what would be the best strategy here. One would > be to use the RTP send time as TS basis. [Thomas Zeng] This is the reason that makes it hard to treat ip/port binding packets as RTP packets. These binding packets are not really media packets, yet according to RTP rules, they would have to be accounted for in RR and SRs. All of a sudden RTSP clients would now need to send SRs back to RTSP servers. That probably won't please implementors of thin RTSP clients. > In general I think we need to further look over this section. Is it a > good thing to use PT=0, i.e. PCM audio with no samples for these > packets? Please comment. [Thomas Zeng] How about not treating binding packets as RTP packets at all? My suggestion would be to use a simple UDP packet that contains an SSRC (the server SSRC as indicated in SETUP response, so as to make it possible to uniquely identify RTP session in the event server is sending RTP packets from a shared UDP port in order to conserve server resources -- a common practice among implementors of large scale servers) ? If you want to indicate that re-transmission of binding packets are taking place, we can put a 4- byte counter in this binding packets as well. That is, the first binding packet is try number 1, the second is try number 2, etc... The fact that this binding packet is smaller than RTP / RTCP header makes it real easy for the server to distinguish between RTP and RTCP packets and the port binding packets. Any other packets would be disgarded. A binding packet with incorrect SSRC or counter are also discarded. > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Tue Apr 29 17:41:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12067 for ; Tue, 29 Apr 2003 17:41:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3TLkLl27814 for mmusic-archive@odin.ietf.org; Tue, 29 Apr 2003 17:46:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLkL827811 for ; Tue, 29 Apr 2003 17:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12043 for ; Tue, 29 Apr 2003 17:40:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AcsD-0000Xk-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 17:42:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AcsD-0000Xh-00 for mmusic-web-archive@ietf.org; Tue, 29 Apr 2003 17:42:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLkB827758; Tue, 29 Apr 2003 17:46:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3TLj1827687 for ; Tue, 29 Apr 2003 17:45:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12009 for ; Tue, 29 Apr 2003 17:39:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Acqq-0000X4-00 for mmusic@ietf.org; Tue, 29 Apr 2003 17:41:24 -0400 Received: from tog-wakko2.prognet.com ([207.188.29.249] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19AcqV-0000Wt-00 for mmusic@ietf.org; Tue, 29 Apr 2003 17:41:03 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19Acqa-0000nU-00; Tue, 29 Apr 2003 14:41:08 -0700 Date: Tue, 29 Apr 2003 14:41:08 -0700 From: Tom Marshall To: Thomas Zeng Cc: "'Magnus Westerlund'" , Aaron Colwell , IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Message-ID: <20030429214108.GI593@real.com> References: <72263E8E8622D611975C0002B32C19D84A7A1F@MISTY> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gTY1JhLGodeuSBqf" Content-Disposition: inline In-Reply-To: <72263E8E8622D611975C0002B32C19D84A7A1F@MISTY> User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --gTY1JhLGodeuSBqf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > No, I need to think over what would be the best strategy here. One would > > be to use the RTP send time as TS basis. > [Thomas Zeng] This is the reason that makes it hard to treat > ip/port binding packets as RTP packets. These binding packets are not rea= lly > media packets, yet according to RTP rules, they would have to be accounted > for in RR and SRs. All of a sudden RTSP clients would now need to send SRs > back to RTSP servers. That probably won't please implementors of thin RT= SP > clients. >=20 >=20 > > In general I think we need to further look over this section. Is it a > > good thing to use PT=3D0, i.e. PCM audio with no samples for these > > packets? Please comment. > [Thomas Zeng] How about not treating binding packets as RTP packets > at all? My suggestion would be to use a simple UDP packet that contains an > SSRC (the server SSRC as indicated in SETUP response, so as to make it > possible to uniquely identify RTP session in the event server is sending = RTP > packets from a shared UDP port in order to conserve server resources -- a > common practice among implementors of large scale servers) ? If you want = to > indicate that re-transmission of binding packets are taking place, we can > put a 4- byte counter in this binding packets as well. That is, the first > binding packet is try number 1, the second is try number 2, etc... The f= act > that this binding packet is smaller than RTP / RTCP header makes it real > easy for the server to distinguish between RTP and RTCP packets and the p= ort > binding packets. Any other packets would be disgarded. A binding packet w= ith > incorrect SSRC or counter are also discarded. I have mixed feelings on this issue. On the one hand, it isn't really an RTP data packet. It's just a binding packet that happens to require a couple of the same values that are in an RTP packet. On the other hand, the RTP header is very well defined, it's pretty short (12 octets), and the PT field is really the only troublesome one. I think the other fields have pretty obvious values. Why can't we say that the binding packet is not an RTP packet but it is formatted to look like one? There may be advantages to masquerading as an RTP packet, especially with firewalls. We can choose some arbitrary value for PT (I think 0 or 127 is logical) and we get the version, extension mechanism, and sequence number for free. What a deal. --=20 Mountain Dew and doughnuts... because breakfast is the most important meal of the day. --gTY1JhLGodeuSBqf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+rvF0qznSmcYu2m8RAi0cAJwK2qUIAoeFYmrtXD7bPLTEc/wGTACeI0i8 RTPniIfEahXF6xWR+qpv+4I= =oogE -----END PGP SIGNATURE----- --gTY1JhLGodeuSBqf-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 02:54:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23732 for ; Wed, 30 Apr 2003 02:54:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U70E101463 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 03:00:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U70E801460 for ; Wed, 30 Apr 2003 03:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23729 for ; Wed, 30 Apr 2003 02:54:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AlW2-0004k0-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 02:56:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AlW1-0004jx-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 02:56:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U6xb801384; Wed, 30 Apr 2003 02:59:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U6wk801340 for ; Wed, 30 Apr 2003 02:58:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23706 for ; Wed, 30 Apr 2003 02:52:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AlUc-0004jQ-00 for mmusic@ietf.org; Wed, 30 Apr 2003 02:55:02 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49] helo=albatross.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19AlUb-0004jM-00 for mmusic@ietf.org; Wed, 30 Apr 2003 02:55:02 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by albatross.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.5.1) with ESMTP id h3U6tdRs015100; Wed, 30 Apr 2003 08:55:39 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id J71XW0CW; Wed, 30 Apr 2003 08:55:38 +0200 Message-ID: <3EAF7323.4050107@era.ericsson.se> Date: Wed, 30 Apr 2003 08:54:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell , IETF MMUSIC WG Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: <3EAEB43A.8030309@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Aaron I hope you don't mind that I again include the MMUSIC list. I think the question and replies should go there. Aaron Colwell wrote: >Hi Magnus, > >Thanks for you response. My comments are inline > >On Tue, 29 Apr 2003, Magnus Westerlund wrote: > > > >>Hi Aaron, >> >>See my answer below inline. >> >>Aaron Colwell wrote: >> >> >> >>>I have a few questions about section 3.2.3 list item 8. It says >>>"For RTCP it starts transmitting RTCP packets according to the rules." >>> >>>1. Does this mean that it starts sending compound SR and SDES packets? >>> >>> >>> >>Depends on the RTP session state. Unless the server has not sent any RTP >>packets yet it must send RR and SDES. If it has sent RTP packets then it >>need to send SR and SDES. >> >> > >I guess I was assuming that if the client is behind a NAT that it won't >get any packets from the server until it sends packets to the server >through the NAT. In this case it seems to me that the only valid thing >for the client to do is send a compound SR and SDES packets initially. > > Yes, If the client is behind a NAT it will require that the client sends its RTCP packets to the server to bind them. This packet shall be a normal RTCP packet. So if RTCP is sent before any RTP packet has been sent, then the client SSRC has status as receiver only and sends RR and SDES. If the RTP packet(s) has been sent then it will have status of active sender and send SR and SDES. This doesn't matter for the binding mechanism. As this is based on SSRC the server shall be able to send replies as soon as one of the client RTCP packets reach the server. > > >>>2. Is the client supposed to created it's own CNAME for this stream of >>> packets or does the CNAME need to be sent from the server to the client? >>> >>> >>> >>The client must set a CNAME of its own. That it must always do when >>sending RTCP in a RTP session. >> >> > >This comment is actually a surprise to me. I always thought that the CNAME >was always specified by an RTP sender. I've always thought that the client >just used the CNAME in the SDES packets sent by the server. Is that not >the case? Perhaps this is something that needs to be clarified in the RTP >spec. It doesn't seem to say much about who generates the CNAMEs and which >CNAMEs are used where. It just says that all compound RTCP packets must >have an SDES packet with CNAME field. > All RTP session participants MUST have its own CNAME independent if he is a active RTP sender or not. I think you should re-read section 6.5.1 of draft-ietf-avt-rtp-new-12.txt. I think this is rather clear there. The perhaps only somewhat confusing think is the use of the word source. It is in some cases meaning participant due to the fact that all participant get a SSRC > > > >>>3. Should the client and server both send RR info to eachother about the >>> RTP packets they are sending? >>> >>> >>> >>Yes, It should report on these packets. >> >> >> >>>4. Are there any requirements for the RTP packet timestamps other than >>> being monotonically increasing? >>> >>> >>> >>No, I need to think over what would be the best strategy here. One would >>be to use the RTP send time as TS basis. >> >> > >I like the idea of using the RTP send time here. Since we are using PT=0 >are the units still in 1/8000 of a second? > > Yes. > > >>In general I think we need to further look over this section. Is it a >>good thing to use PT=0, i.e. PCM audio with no samples for these >>packets? Please comment. >> >> >> > >I don't know if using PT=0 is a good idea or not. I'm struggling a little >bit with what it means to get a packet without any payload data. In the >case of PCM audio it doesn't seem to really matter, but in other payload >formats it might. We might want to have a reserved payload type for this >type of packet. That way we could also include some sort of challenge like >you mention later in the document. Whatever challenge mechanism we devise, >we should have something similar for RTCP as well. In the RTCP case we >could probably just add a new SDES item type and do the challenge in >there. > > Yes, this is something that needs more considerations. I think Thomas has some other ideas on how to accomplish this. I would also like a binding payload format with its own static payload type. However I don't know what possibilities exist to get such developed in a reasonable time frame. >I agree that we should look over this section more. A few weeks ago I had >to solve this NAT problem for streaming to a mobile phone. I didn't >really have any specs to reference so I made up my own solution. I like >this solution much better and I'd like to see this developed more so that >we'll have an interoperable solution. > > Yes, there is a total lack of specified solutions for RTSP. The RTSP NAT draft is our attempt to solve this. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 04:28:56 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25249 for ; Wed, 30 Apr 2003 04:28:56 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U8YNV16038 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 04:34:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8YN816035 for ; Wed, 30 Apr 2003 04:34:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25246 for ; Wed, 30 Apr 2003 04:28:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Amz7-00058L-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 04:30:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Amz7-00058I-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 04:30:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8YF816026; Wed, 30 Apr 2003 04:34:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U8Xb815982 for ; Wed, 30 Apr 2003 04:33:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25216; Wed, 30 Apr 2003 04:27:39 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AmyN-00057t-00; Wed, 30 Apr 2003 04:29:51 -0400 Received: from gw-nl3.philips.com ([212.153.190.5]) by ietf-mx with esmtp (Exim 4.12) id 19AmyM-00057q-00; Wed, 30 Apr 2003 04:29:50 -0400 Received: from smtpscan-nl2.philips.com (smtpscan-nl2.philips.com [130.139.36.22]) by gw-nl3.philips.com (Postfix) with ESMTP id D12548FDAF; Wed, 30 Apr 2003 10:30:27 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl2.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA26669; Wed, 30 Apr 2003 10:30:27 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id KAA17380; Wed, 30 Apr 2003 10:30:25 +0200 (MET DST) Subject: RE: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions To: Thomas Zeng Cc: Aaron Colwell , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 30 Apr 2003 10:22:35 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 30/04/2003 10:31:28 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , all, This seems to be getting pretty complicated and tricky.... Actually in the ligth of this discussion the usage of STUN looks so much more straigthforward no ? regards Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: "'Magnus Westerlund'" Aaron Colwell IETF MMUSIC WG cc: (bcc: Philippe Gentric/MP4-SUR/CE/PHILIPS) Thomas Zeng Subject: RE: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Classification: Sent by: mmusic-admin@ietf.org 29/04/2003 23:24 > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] > > Sent: Tuesday, April 29, 2003 11:04 AM > To: Aaron Colwell; IETF MMUSIC WG > Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions > > Hi Aaron, > > See my answer below inline. > > Aaron Colwell wrote: > > >I have a few questions about section 3.2.3 list item 8. It says > >"For RTCP it starts transmitting RTCP packets according to the rules." > > > >1. Does this mean that it starts sending compound SR and SDES packets? > > > > Depends on the RTP session state. Unless the server has not sent any RTP > packets yet it must send RR and SDES. If it has sent RTP packets then it > need to send SR and SDES. > > >2. Is the client supposed to created it's own CNAME for this stream of > > packets or does the CNAME need to be sent from the server to the > client? > > > The client must set a CNAME of its own. That it must always do when > sending RTCP in a RTP session. > > >3. Should the client and server both send RR info to eachother about the > > RTP packets they are sending? > > > > Yes, It should report on these packets. > > >4. Are there any requirements for the RTP packet timestamps other than > > being monotonically increasing? > > > > No, I need to think over what would be the best strategy here. One would > be to use the RTP send time as TS basis. [Thomas Zeng] This is the reason that makes it hard to treat ip/port binding packets as RTP packets. These binding packets are not really media packets, yet according to RTP rules, they would have to be accounted for in RR and SRs. All of a sudden RTSP clients would now need to send SRs back to RTSP servers. That probably won't please implementors of thin RTSP clients. > In general I think we need to further look over this section. Is it a > good thing to use PT=0, i.e. PCM audio with no samples for these > packets? Please comment. [Thomas Zeng] How about not treating binding packets as RTP packets at all? My suggestion would be to use a simple UDP packet that contains an SSRC (the server SSRC as indicated in SETUP response, so as to make it possible to uniquely identify RTP session in the event server is sending RTP packets from a shared UDP port in order to conserve server resources -- a common practice among implementors of large scale servers) ? If you want to indicate that re-transmission of binding packets are taking place, we can put a 4- byte counter in this binding packets as well. That is, the first binding packet is try number 1, the second is try number 2, etc... The fact that this binding packet is smaller than RTP / RTCP header makes it real easy for the server to distinguish between RTP and RTCP packets and the port binding packets. Any other packets would be disgarded. A binding packet with incorrect SSRC or counter are also discarded. > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ 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 mailnull@www1.ietf.org Wed Apr 30 05:34:08 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26537 for ; Wed, 30 Apr 2003 05:34:08 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3U9db026481 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 05:39:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U9db826474 for ; Wed, 30 Apr 2003 05:39:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26518 for ; Wed, 30 Apr 2003 05:33:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Ao0E-0005WX-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 05:35:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ao0D-0005WS-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 05:35:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U9dR826409; Wed, 30 Apr 2003 05:39:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3U9cI826189 for ; Wed, 30 Apr 2003 05:38:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26507 for ; Wed, 30 Apr 2003 05:32:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Anyw-0005WH-00 for mmusic@ietf.org; Wed, 30 Apr 2003 05:34:30 -0400 Received: from gorilla.mchh.siemens.de ([194.138.158.18]) by ietf-mx with esmtp (Exim 4.12) id 19Anyw-0005WB-00 for mmusic@ietf.org; Wed, 30 Apr 2003 05:34:30 -0400 Received: from moody.mchh.siemens.de ([139.21.205.85]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id LAA21363; Wed, 30 Apr 2003 11:34:51 +0200 (MET DST) Received: from mchh247e.demchh201e.icn.siemens.de (mchh247e.mchh.siemens.de [139.21.200.57]) by moody.mchh.siemens.de (8.9.3/8.9.1) with ESMTP id LAA14110; Wed, 30 Apr 2003 11:34:53 +0200 (MET DST) Received: by mchh247e.mchh.siemens.de with Internet Mail Service (5.5.2656.59) id ; Wed, 30 Apr 2003 11:34:32 +0200 Message-ID: From: Kreuter Ruediger To: "'Jonathan Rosenberg'" Cc: Flemming Andreasen , Stephen Casner , Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Wed, 30 Apr 2003 11:34:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U9cI826190 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-MIME-Autoconverted: from 8bit to quoted-printable by www1.ietf.org id h3U9dR826409 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h3U9db826474 Content-Transfer-Encoding: 8bit Sending a reinvite for a switchover from voice to voiceband data (incl. fax) is applicable. But Rajesh's example below is text/t140, that is, we are "talking" about TTY/TDD. This is completely different because the transmission of TTY characters and voice can be mixed in any way on a TDM line, and therefore must be transferable in a VoIP connection too. That is, it can be that during a connection a sender types some characters on his TTY, then he speeks some sentences, then he types some characters ... You don't really want to send re-invites every couple of sentences, do you ? The only practicable way is to mix text/t140 and audio/G7xx the same way as audio/RFC2833 and audio/G7xx. Another good reason to mix these media types is performance. Depending on the TTY terminal type, a TTY transmission can start without a startup sequence as it is used by fax or data modem transmissions. Therefore the switch over to text/t140 must be very fast otherwise you loose characters. And the sending person doesn't know if his characters were lost or not. Now imagine a deaf person calling an emergancy line ... Sending a re-invite to switch over the connection may use up a second in a heavy loaded network. Regards, Ruediger Kreuter Ruediger.Kreuter@siemens.com > -----Ursprüngliche Nachricht----- > Von: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Gesendet: Dienstag, 29. April 2003 01:11 > An: Flemming Andreasen > Cc: Stephen Casner; Rajesh Kumar; Colin Perkins; mmusic@ietf.org; > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > paulej@cisco.com > Betreff: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > inline. > > Flemming Andreasen wrote: > > > > Stephen Casner wrote: > > > > > >>Rajesh, > >> > >> > >>>Is the use of multiple 'm=' lines with the same port > number within an SDP > >>>descriptor permitted? > >> > >>Presuming that the multiple m= lines are all RTP/AVP, then doing so > >>causes all of the payload formats listed on the m= lines to become > >>part of a single RTP session (unless they are distinguished by some > >>other aspect of addressing). Section 5.2 of the RTP spec addresses > >>NOT multiplexing different media in the same RTP session. > >> > >> > >>>In SDP, as it is defined, all the media formats on an 'm=' > line are of the > >>>same media type (e.g. audio, image, text etc.). > >>> > >>>Now consider the case in which two RTP media formats can > use a destination > >>>port but are registered under different MIME types. For > example, text/t140 > >>>and audio/PCMU. In this case, there is no recourse except > to use multiple > >>>media lines with the same port number. For example: > >> > >>The "can use a destination port" is the tricky part. We > may not agree. > >> > > > > > > We also seem to be entering a bit of a gray area here in > terms of offer/answer > > (RFC 3264). It's not clear that the definition of "m=" > lines and media streams > > allow for something like this; for sure the parties would > have to recognize that > > the two "m=" lines in fact are one media stream and hence > should not be sending > > to "both" at the same time. However, I'm not aware of such > behavior being > > specified anywhere. > > Using two m lines to represent alternate encodings for a > stream is not > consistent with the offer/answer model, IMHO. RFC 3264 has mechanisms > for transitioning from audio to fax, for example, but these require a > re-invite to do: > > 8.3.3 Changing Media Types > > The media type (audio, video, etc.) for a stream MAY be > changed. It > is RECOMMENDED that the media type be changed (as opposed > to adding a > new stream), when the same logical data is being > conveyed, but just > in a different media format. This is particularly useful for > changing between voiceband fax and fax in a single > stream, which are > both separate media types. To do this, the offerer creates a new > media description, with a new media type, in place of the > description > in the previous SDP which is to be changed. > > > -Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 10:43:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06483 for ; Wed, 30 Apr 2003 10:43:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UEmaJ24490 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 10:48:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UEma824487 for ; Wed, 30 Apr 2003 10:48:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06462 for ; Wed, 30 Apr 2003 10:42:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Asp8-0007kB-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 10:44:42 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Asp8-0007k8-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 10:44:42 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UEmS824472; Wed, 30 Apr 2003 10:48:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UElm824397 for ; Wed, 30 Apr 2003 10:47:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06384; Wed, 30 Apr 2003 10:41:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AsoM-0007jL-00; Wed, 30 Apr 2003 10:43:54 -0400 Received: from tog-wakko2.prognet.com ([207.188.29.249] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19AsoL-0007jI-00; Wed, 30 Apr 2003 10:43:53 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19AsoB-0001Le-00; Wed, 30 Apr 2003 07:43:43 -0700 Date: Wed, 30 Apr 2003 07:43:43 -0700 From: Tom Marshall To: philippe.gentric@philips.com Cc: Thomas Zeng , Aaron Colwell , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Message-ID: <20030430144343.GA5170@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 30, 2003 at 10:22:35AM +0200, philippe.gentric@philips.com wrot= e: > all, >=20 > This seems to be getting pretty complicated and tricky.... Unfortunately, that is the nature of NAT. > Actually in the ligth of this discussion the usage of STUN looks > so much more straigthforward no ? Well, the case of a STUN server that is a third party to the client and server is quite straightforward. But that doesn't work with 5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And that, really, is no more or less complicated than "symmetric rtp". They are mostly equivalent solutions. It only looks less complicated at this point in time because the format for STUN packets has already been agreed upon, and we are still looking at the format for the "symmetric rtp" packets. --=20 Did you ever notice that fat chance and slim chance mean the same thing? --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+r+EfqznSmcYu2m8RAiiWAJ9tBmM4GulCo7TSTelHbQ7WxyQ64wCeKAbU OZGFuJdqVdAD2WVIl+ImBmM= =FlJ+ -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 10:59:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07779 for ; Wed, 30 Apr 2003 10:59:51 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UF5Q431790 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 11:05:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UF5Q831787 for ; Wed, 30 Apr 2003 11:05:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07650 for ; Wed, 30 Apr 2003 10:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19At5Q-0000FG-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:01:32 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19At5O-0000F6-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:01:30 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UF5I831770; Wed, 30 Apr 2003 11:05:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UF4t831671 for ; Wed, 30 Apr 2003 11:04:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07539; Wed, 30 Apr 2003 10:58:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19At4v-0000DA-00; Wed, 30 Apr 2003 11:01:01 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19At4u-0000C3-00; Wed, 30 Apr 2003 11:01:00 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3UF16dh004425; Wed, 30 Apr 2003 11:01:06 -0400 (EDT) Message-ID: <3EAFE52A.8080805@dynamicsoft.com> Date: Wed, 30 Apr 2003 11:00:58 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: philippe.gentric@philips.com, Thomas Zeng , Aaron Colwell , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: <20030430144343.GA5170@real.com> In-Reply-To: <20030430144343.GA5170@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: > >> Actually in the ligth of this discussion the usage of STUN looks so >> much more straigthforward no ? I was thinking the same thing. > > > Well, the case of a STUN server that is a third party to the client > and server is quite straightforward. But that doesn't work with > 5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And > that, really, is no more or less complicated than "symmetric rtp". > They are mostly equivalent solutions. It only looks less complicated > at this point in time because the format for STUN packets has already > been agreed upon, and we are still looking at the format for the > "symmetric rtp" packets. Its an issue of - why are you inventing yet another thing when we already have something on the table? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 11:52:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09719 for ; Wed, 30 Apr 2003 11:52:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UFvvF12551 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 11:57:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFvv812548 for ; Wed, 30 Apr 2003 11:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09683 for ; Wed, 30 Apr 2003 11:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AtuE-0000kS-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AtuD-0000kP-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:54:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFvS812511; Wed, 30 Apr 2003 11:57:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFuM812458 for ; Wed, 30 Apr 2003 11:56:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09622; Wed, 30 Apr 2003 11:50:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Atsh-0000j7-00; Wed, 30 Apr 2003 11:52:27 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.wise.edt.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Atsg-0000j4-00; Wed, 30 Apr 2003 11:52:27 -0400 Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.6) with ESMTP id h3UFr252010437; Wed, 30 Apr 2003 17:53:02 +0200 (MEST) Received: from era.ericsson.se (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id J71X72LT; Wed, 30 Apr 2003 17:53:01 +0200 Message-ID: <3EAFF116.5060502@era.ericsson.se> Date: Wed, 30 Apr 2003 17:51:50 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Tom Marshall , philippe.gentric@philips.com, Thomas Zeng , Aaron Colwell , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: <20030430144343.GA5170@real.com> <3EAFE52A.8080805@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jonathan, Jonathan Rosenberg wrote: > Its an issue of - why are you inventing yet another thing when we > already have something on the table? Well, I think I might have to crawl to the cross. I don't like the multiplexing of RTP & RTCP with STUN. However it seems that symmetric RTP will probably be only slightly less evil. It is the RTP binding part that I am worried over. If we had a binding payload with a static PT I would not hesitate a minute. However without it the implications is a bit more problematic. RTCP is obviously not a problem as the binding RTCP packets are normal and can be forwarded to the normal processing without any consideration. However one issue that remains is that a server will most likely need to have announced ports for RTP and RTCP which can't be changed and for which all RTP/RTCP and STUN traffic is directed too. From minimizing setup time a STUN solution for symmetric NATs should probably get the SDP, Do all STUN request in parallel for the media streams to the in SDP announce ports. Then do SETUP request with the learned destination addresses. The other alternative sequence where a client learns the servers STUN port numbers through RTSP would require two SETUP requests. Doesn't this make the server vulnerable? Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 11:54:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09859 for ; Wed, 30 Apr 2003 11:54:48 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UG0PH12718 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 12:00:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG0P812715 for ; Wed, 30 Apr 2003 12:00:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09847 for ; Wed, 30 Apr 2003 11:54:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Atwc-0000n8-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:56:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Atwb-0000n5-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 11:56:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG05812706; Wed, 30 Apr 2003 12:00:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UFxa812657 for ; Wed, 30 Apr 2003 11:59:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09825; Wed, 30 Apr 2003 11:53:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Atvp-0000mi-00; Wed, 30 Apr 2003 11:55:41 -0400 Received: from flawless.real.com ([207.188.7.222]) by ietf-mx with esmtp (Exim 4.12) id 19Atvo-0000mM-00; Wed, 30 Apr 2003 11:55:40 -0400 Received: from raven.dev.prognet.com ([::ffff:172.22.22.16]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Wed, 30 Apr 2003 08:55:46 -0700 Date: Wed, 30 Apr 2003 09:00:05 -0700 (PDT) From: Aaron Colwell To: Jonathan Rosenberg cc: Tom Marshall , philippe.gentric@philips.com, Thomas Zeng , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions In-Reply-To: <3EAFE52A.8080805@dynamicsoft.com> Message-ID: References: <20030430144343.GA5170@real.com> <3EAFE52A.8080805@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit In my opinion requiring an implementation to use STUN to do this is a pretty large requirement. It means the client will have to have a TLS implementation right? The cost in code space or CPU usage of the TLS implementation may be too high for some embedded applications like 3GPP devices. I think demultiplexing the STUN and RTP/RTCP messages could get tricky. The STUN solution also won't work behind a Symmetric NAT unless the server implements STUN as well. I just feel that the use of STUN puts too many requirements on the client and server. I agree with Thomas though that by making these binding packets RTP data packets, the client and server end up having to do much more RTCP protocol then we really need. We really just need a packet that looks like an RTP packet like Tom Marshall said. We could just get one of the reserved payload types assigned for binding packets and specify that these packets do not require the normal RTCP chat associated with a data stream. Old implementations will keep state for these packets and send RTCP chat for the data, but newer impelementations will know that they don't have to care about these packets. What do people think? Aaron On Wed, 30 Apr 2003, Jonathan Rosenberg wrote: > > > Tom Marshall wrote: > > > > >> Actually in the ligth of this discussion the usage of STUN looks so > >> much more straigthforward no ? > > I was thinking the same thing. > > > > > > > Well, the case of a STUN server that is a third party to the client > > and server is quite straightforward. But that doesn't work with > > 5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And > > that, really, is no more or less complicated than "symmetric rtp". > > They are mostly equivalent solutions. It only looks less complicated > > at this point in time because the format for STUN packets has already > > been agreed upon, and we are still looking at the format for the > > "symmetric rtp" packets. > > Its an issue of - why are you inventing yet another thing when we > already have something on the table? > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 12:00:33 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10032 for ; Wed, 30 Apr 2003 12:00:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UG69Y21780 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 12:06:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG69821777 for ; Wed, 30 Apr 2003 12:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10024 for ; Wed, 30 Apr 2003 12:00:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Au2A-0000q5-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 12:02:14 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Au29-0000q2-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 12:02:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG66821762; Wed, 30 Apr 2003 12:06:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UG27819499 for ; Wed, 30 Apr 2003 12:02:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09905; Wed, 30 Apr 2003 11:56:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AtyG-0000o0-00; Wed, 30 Apr 2003 11:58:12 -0400 Received: from tog-wakko2.prognet.com ([207.188.29.249] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 19AtyF-0000nw-00; Wed, 30 Apr 2003 11:58:12 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 19Atyj-0001PR-00; Wed, 30 Apr 2003 08:58:41 -0700 Date: Wed, 30 Apr 2003 08:58:41 -0700 From: Tom Marshall To: Jonathan Rosenberg Cc: philippe.gentric@philips.com, Thomas Zeng , Aaron Colwell , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Message-ID: <20030430155841.GA5361@real.com> References: <20030430144343.GA5170@real.com> <3EAFE52A.8080805@dynamicsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <3EAFE52A.8080805@dynamicsoft.com> User-Agent: Mutt/1.5.3i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >Well, the case of a STUN server that is a third party to the client > >and server is quite straightforward. But that doesn't work with > >5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And > >that, really, is no more or less complicated than "symmetric rtp". > >They are mostly equivalent solutions. It only looks less complicated > >at this point in time because the format for STUN packets has already > >been agreed upon, and we are still looking at the format for the > >"symmetric rtp" packets. >=20 > Its an issue of - why are you inventing yet another thing when we=20 > already have something on the table? I can think of two reasons: 1. The technique is already in use, and has been proven successful. We are trying to document that technique. 2. It has advantages over STUN. It is more successful than nonmultiplexed STUN (eg. with 5-tuple NATs) and it does not require any protocol multiplexing to achieve maximum usefulness (it's a cleaner solution). I can see where STUN may have uses for protocols other than RTP, and that is fine. But to imply that STUN is the one grand solution and we shouldn't pursue symmetric rtp is, in my opinion, a mistake. --=20 There is nothing new under the sun, but there are lots of old things we don't know yet. -- Ambrose Bierce --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+r/KxqznSmcYu2m8RAsTKAJ9DjKllSoC33FNynzlF/k8G8wVTNwCfQihs sCAZ3iKT60uk6RImn+VRFQo= =Zqlu -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 13:27:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13447 for ; Wed, 30 Apr 2003 13:27:10 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UHWne01875 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 13:32:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHWn801870 for ; Wed, 30 Apr 2003 13:32:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13443 for ; Wed, 30 Apr 2003 13:26:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AvNz-0001hS-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 13:28:51 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AvNz-0001hP-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 13:28:51 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHWC832163; Wed, 30 Apr 2003 13:32:12 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHVH826562 for ; Wed, 30 Apr 2003 13:31:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13408; Wed, 30 Apr 2003 13:25:07 -0400 (EDT) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AvMW-0001h6-00; Wed, 30 Apr 2003 13:27:20 -0400 Received: from [212.153.235.109] (helo=gw-nl5.philips.com ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 19AvMV-0001h3-00; Wed, 30 Apr 2003 13:27:19 -0400 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl5.philips.com (Postfix) with ESMTP id E19792C3D1; Wed, 30 Apr 2003 19:27:57 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl3.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA23197; Wed, 30 Apr 2003 19:27:57 +0200 (MET DST) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl1.philips.com (8.9.3-p1/8.8.5-1.2.2m-19990317) with ESMTP id TAA15922; Wed, 30 Apr 2003 19:27:56 +0200 (MET DST) Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions To: Aaron Colwell Cc: Jonathan Rosenberg , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org, Tom Marshall , Thomas Zeng X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Wed, 30 Apr 2003 19:20:04 +0200 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 30/04/2003 19:28:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , TLS ? but there is no TLS involved in the type of STUN usage we want right ? it is just sending a few UDP packets with the right (STUN) syntax, nothing more Philippe Gentric Software Architect Philips MP4Net philippe.gentric@philips.com http://www.platform4.philips.com To: Jonathan Rosenberg cc: Tom Marshall Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 Thomas Zeng Aaron Colwell "'Magnus Westerlund'" IETF MMUSIC WG mmusic-admin@ietf.org 30/04/2003 18:00 Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions Classification: In my opinion requiring an implementation to use STUN to do this is a pretty large requirement. It means the client will have to have a TLS implementation right? The cost in code space or CPU usage of the TLS implementation may be too high for some embedded applications like 3GPP devices. I think demultiplexing the STUN and RTP/RTCP messages could get tricky. The STUN solution also won't work behind a Symmetric NAT unless the server implements STUN as well. I just feel that the use of STUN puts too many requirements on the client and server. I agree with Thomas though that by making these binding packets RTP data packets, the client and server end up having to do much more RTCP protocol then we really need. We really just need a packet that looks like an RTP packet like Tom Marshall said. We could just get one of the reserved payload types assigned for binding packets and specify that these packets do not require the normal RTCP chat associated with a data stream. Old implementations will keep state for these packets and send RTCP chat for the data, but newer impelementations will know that they don't have to care about these packets. What do people think? Aaron On Wed, 30 Apr 2003, Jonathan Rosenberg wrote: > > > Tom Marshall wrote: > > > > >> Actually in the ligth of this discussion the usage of STUN looks so > >> much more straigthforward no ? > > I was thinking the same thing. > > > > > > > Well, the case of a STUN server that is a third party to the client > > and server is quite straightforward. But that doesn't work with > > 5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And > > that, really, is no more or less complicated than "symmetric rtp". > > They are mostly equivalent solutions. It only looks less complicated > > at this point in time because the format for STUN packets has already > > been agreed upon, and we are still looking at the format for the > > "symmetric rtp" packets. > > Its an issue of - why are you inventing yet another thing when we > already have something on the table? > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Scientist Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 13:46:34 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14403 for ; Wed, 30 Apr 2003 13:46:34 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UHqBN08458 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 13:52:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHqB808455 for ; Wed, 30 Apr 2003 13:52:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14378 for ; Wed, 30 Apr 2003 13:46:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Avgj-0001wc-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 13:48:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Avgj-0001wZ-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 13:48:13 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHq5808443; Wed, 30 Apr 2003 13:52:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UHpW808367 for ; Wed, 30 Apr 2003 13:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14358; Wed, 30 Apr 2003 13:45:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Avg7-0001wG-00; Wed, 30 Apr 2003 13:47:35 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 19Avg5-0001vc-00; Wed, 30 Apr 2003 13:47:33 -0400 Received: from raven.dev.prognet.com ([::ffff:172.22.22.16]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 30 Apr 2003 10:47:35 -0700 Date: Wed, 30 Apr 2003 10:51:55 -0700 (PDT) From: Aaron Colwell To: philippe.gentric@philips.com cc: Jonathan Rosenberg , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org, Tom Marshall , Thomas Zeng Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions In-Reply-To: Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Are we intending to skip over the Shared Secret part of the STUN protocol? On pages 7 and 24 of RFC 3489 it talks about RTP use scenarios specifically and it says the first step is to send a shared secret request. On pages 6 and 8 the RFC says that shared secret requests are always sent over TLS. Aaron On Wed, 30 Apr 2003 philippe.gentric@philips.com wrote: > TLS ? > > but there is no TLS involved in the type of STUN usage we want > right ? it is just sending a few UDP packets with the right (STUN) syntax, > nothing more > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.platform4.philips.com > > > > > To: Jonathan Rosenberg > cc: Tom Marshall > Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1 > Thomas Zeng > Aaron Colwell "'Magnus Westerlund'" > IETF MMUSIC WG > mmusic-admin@ietf.org > 30/04/2003 18:00 Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions > > Classification: > > > > > > > In my opinion requiring an implementation to use STUN to do this is a > pretty large requirement. It means the client will have to have a TLS > implementation right? The cost in code space or CPU usage of the TLS > implementation may be too high for some embedded applications like 3GPP > devices. I think demultiplexing the STUN and RTP/RTCP messages could get > tricky. The STUN solution also won't work behind a Symmetric NAT unless > the server implements STUN as well. I just feel that the use of STUN puts > too many requirements on the client and server. > > I agree with Thomas though that by making these binding packets RTP data > packets, the client and server end up having to do much more RTCP protocol > then we really need. We really just need a packet that looks like an RTP > packet like Tom Marshall said. We could just get one of the reserved > payload types assigned for binding packets and specify that these packets > do not require the normal RTCP chat associated with a data stream. Old > implementations will keep state for these packets and send RTCP chat for > the data, but newer impelementations will know that they don't have to > care about these packets. > > What do people think? > > Aaron > > On Wed, 30 Apr 2003, Jonathan Rosenberg wrote: > > > > > > > Tom Marshall wrote: > > > > > > > >> Actually in the ligth of this discussion the usage of STUN looks so > > >> much more straigthforward no ? > > > > I was thinking the same thing. > > > > > > > > > > > Well, the case of a STUN server that is a third party to the client > > > and server is quite straightforward. But that doesn't work with > > > 5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And > > > that, really, is no more or less complicated than "symmetric rtp". > > > They are mostly equivalent solutions. It only looks less complicated > > > at this point in time because the format for STUN packets has already > > > been agreed upon, and we are still looking at the format for the > > > "symmetric rtp" packets. > > > > Its an issue of - why are you inventing yet another thing when we > > already have something on the table? > > > > -Jonathan R. > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Scientist Parsippany, NJ 07054-2711 > > dynamicsoft > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 16:44:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23488 for ; Wed, 30 Apr 2003 16:44:43 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UKoPe04173 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 16:50:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKoP804170 for ; Wed, 30 Apr 2003 16:50:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23485 for ; Wed, 30 Apr 2003 16:44:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AyTA-0003T5-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 16:46:24 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AyT9-0003T2-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 16:46:23 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKoD804119; Wed, 30 Apr 2003 16:50:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKnJ803993 for ; Wed, 30 Apr 2003 16:49:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23460; Wed, 30 Apr 2003 16:42:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AyRc-0003SO-00; Wed, 30 Apr 2003 16:44:48 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19AyRW-0003Rg-00; Wed, 30 Apr 2003 16:44:42 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3UKhPdh004646; Wed, 30 Apr 2003 16:43:26 -0400 (EDT) Message-ID: <3EB03569.8090105@dynamicsoft.com> Date: Wed, 30 Apr 2003 16:43:21 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Colwell CC: Tom Marshall , philippe.gentric@philips.com, Thomas Zeng , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: <20030430144343.GA5170@real.com> <3EAFE52A.8080805@dynamicsoft.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I think there are some misconceptions here. More inline. Aaron Colwell wrote: > In my opinion requiring an implementation to use STUN to do this is a > pretty large requirement. It means the client will have to have a TLS > implementation right? No. In the usage of STUN here, which is peer-to-peer, you would not use TLS. You would not need most of the features of STUN. Just the HMAC authentication, and the baseline case of sending a response to the place the request came from (i.e., no change flags, no response address, etc.). Really just a "ping" plus an HMAC over the address that gets returned. The cost in code space or CPU usage of the TLS > implementation may be too high for some embedded applications like 3GPP > devices. I think demultiplexing the STUN and RTP/RTCP messages could get > tricky. The STUN solution also won't work behind a Symmetric NAT unless > the server implements STUN as well. I just feel that the use of STUN puts > too many requirements on the client and server. The idea is that the RTSP server implements STUN, yes. Muxing the RTP and STUN is how you deal with symmetric RTP. How is that different from having the RTSP server implement the new "fake RTP", and muxing it with regular RTP? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 16:46:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23527 for ; Wed, 30 Apr 2003 16:46:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UKqVl04492 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 16:52:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKqV804489 for ; Wed, 30 Apr 2003 16:52:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23515 for ; Wed, 30 Apr 2003 16:46:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AyVC-0003TW-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 16:48:30 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AyVB-0003TT-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 16:48:29 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKq4804404; Wed, 30 Apr 2003 16:52:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UKp1804279 for ; Wed, 30 Apr 2003 16:51:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23503; Wed, 30 Apr 2003 16:44:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AyTk-0003TA-00; Wed, 30 Apr 2003 16:47:00 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 19AyTe-0003T1-00; Wed, 30 Apr 2003 16:46:54 -0400 Received: from dynamicsoft.com ([63.113.46.55]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h3UKkndh004649; Wed, 30 Apr 2003 16:46:49 -0400 (EDT) Message-ID: <3EB03636.8050805@dynamicsoft.com> Date: Wed, 30 Apr 2003 16:46:46 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: philippe.gentric@philips.com, Thomas Zeng , Aaron Colwell , "'Magnus Westerlund'" , IETF MMUSIC WG , mmusic-admin@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions References: <20030430155841.GA5361@real.com> In-Reply-To: <20030430155841.GA5361@real.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tom Marshall wrote: >>>Well, the case of a STUN server that is a third party to the client >>>and server is quite straightforward. But that doesn't work with >>>5-tuple NAT setups, so we have the RTP/STUN multiplexing case. And >>>that, really, is no more or less complicated than "symmetric rtp". >>>They are mostly equivalent solutions. It only looks less complicated >>>at this point in time because the format for STUN packets has already >>>been agreed upon, and we are still looking at the format for the >>>"symmetric rtp" packets. >> >>Its an issue of - why are you inventing yet another thing when we >>already have something on the table? > > > I can think of two reasons: > > 1. The technique is already in use, and has been proven successful. We > are > trying to document that technique. IETF proposed standards are not about documenting existing technique. They are about proposing the right solution for all to implement. > > 2. It has advantages over STUN. It is more successful than > nonmultiplexed > STUN (eg. with 5-tuple NATs) and it does not require any protocol > multiplexing to achieve maximum usefulness (it's a cleaner solution). The only argument you are making here is that multiplexing is ugly. To that I agree. But, if you want these fake RTP packets to not affect RTCP, you are already basically saying that you are multiplexing a non-RTP protocol on the RTP port. So I dont see the difference really. > > I can see where STUN may have uses for protocols other than RTP, and > that is > fine. But to imply that STUN is the one grand solution and we shouldn't > pursue symmetric rtp is, in my opinion, a mistake. > Well, as is pointed out in my ICE proposal: http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-00.txt The general approach solves a ton more cases than symmetric RTP alone will. If you ever think that you will want RTSP in peer-to-peer cases, symmetric RTP isnt going to cut it. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Scientist Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 17:54:18 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25412 for ; Wed, 30 Apr 2003 17:54:18 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UM02G04418 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 18:00:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UM02804415 for ; Wed, 30 Apr 2003 18:00:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25404 for ; Wed, 30 Apr 2003 17:53:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AzYG-0003v0-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 17:55:44 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AzYF-0003um-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 17:55:43 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ULxH804205; Wed, 30 Apr 2003 17:59:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ULl6802465 for ; Wed, 30 Apr 2003 17:47:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25124 for ; Wed, 30 Apr 2003 17:40:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AzLz-0003r0-00 for mmusic@ietf.org; Wed, 30 Apr 2003 17:43:04 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19AzLu-0003qg-00 for mmusic@ietf.org; Wed, 30 Apr 2003 17:42:58 -0400 Received: from cisco.com (sjc-vpn1-254.cisco.com [10.21.96.254]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h3ULgjua017032; Wed, 30 Apr 2003 14:42:46 -0700 (PDT) Message-ID: <3EB04355.CB99D6DE@cisco.com> Date: Wed, 30 Apr 2003 17:42:45 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kreuter Ruediger CC: "'Jonathan Rosenberg'" , Stephen Casner , Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kreuter Ruediger wrote: > Sending a reinvite for a switchover from voice > to voiceband data (incl. fax) is applicable. > But Rajesh's example below is text/t140, that > is, we are "talking" about TTY/TDD. This is > completely different because the transmission > of TTY characters and voice can be mixed in > any way on a TDM line, and therefore must be > transferable in a VoIP connection too. > That is, it can be that during a connection > a sender types some characters on his TTY, > then he speeks some sentences, then he types > some characters ... > You don't really want to send re-invites > every couple of sentences, do you ? > The only practicable way is to mix text/t140 > and audio/G7xx the same way as audio/RFC2833 > and audio/G7xx. Right - as long as both the transport and the underlying "type" of media (not to be confused with MIME type which I think ends up being a bit too restrictive) is the same, this should be just fine. For example, let's say we defined a T.38 RTP payload format, but we were still using the existing "image/t38" MIME type, then it should be perfectly fine to switch between T.38 RTP packets and say PCMU. However, mixing different types of media, such as audio and video, or different types of transport, such as RTP/AVP and image/udptl for non-RTP T.38 fax is clearly not a good idea. > > Another good reason to mix these media types > is performance. Depending on the TTY terminal > type, a TTY transmission can start without a > startup sequence as it is used by fax or data > modem transmissions. Therefore the switch over > to text/t140 must be very fast otherwise you > loose characters. And the sending person doesn't > know if his characters were lost or not. > Now imagine a deaf person calling an emergancy > line ... > Sending a re-invite to switch over the connection > may use up a second in a heavy loaded network. Agreed - you really need a solution that enables you to switch on the fly, however currently we don't have that when the top-level MIME types differ (note that FID and ALT don't give you these capabilities either). The problem is, that SDP currently lacks a mechanism that would enable us to negotiate different top-level MIME types in a single media stream. This can however be addressed fairly easily by writing an extension to offer/answer that uses SIMCAP (RFC 3407) capabilities during negotiation. If there is interest, I can write something up. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailnull@www1.ietf.org Wed Apr 30 18:55:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28663 for ; Wed, 30 Apr 2003 18:55:32 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UN1HG19285 for mmusic-archive@odin.ietf.org; Wed, 30 Apr 2003 19:01:17 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UN1H819282 for ; Wed, 30 Apr 2003 19:01:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28598 for ; Wed, 30 Apr 2003 18:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0Vl-0004KZ-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 18:57:13 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19B0Vk-0004KE-00 for mmusic-web-archive@ietf.org; Wed, 30 Apr 2003 18:57:12 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UN0m816066; Wed, 30 Apr 2003 19:00:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UMvY815925 for ; Wed, 30 Apr 2003 18:57:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28451 for ; Wed, 30 Apr 2003 18:51:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19B0Rv-0004Hg-00 for mmusic@ietf.org; Wed, 30 Apr 2003 18:53:15 -0400 Received: from host-216-153-163-170.man.choiceone.net ([216.153.163.170] helo=www.frogsoup.org) by ietf-mx with esmtp (Exim 4.12) id 19B0Rk-0004HQ-00 for mmusic@ietf.org; Wed, 30 Apr 2003 18:53:05 -0400 Received: from yon-lattitude.rfdsoftware.com ([68.64.104.130]) (authenticated) by hither.rfdsoftware.com (8.10.2/8.10.2) with ESMTP id h3UMmo827114 for ; Wed, 30 Apr 2003 18:48:55 -0400 Message-Id: <5.1.1.6.0.20030430184520.039e2520@mail.rfdsoftware.com> X-Sender: yon.ietf@mail.rfdsoftware.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 30 Apr 2003 18:51:12 -0400 To: mmusic@ietf.org From: David Yon Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] A proposal for comedia-06 security section (repeated) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , At the risk of being rude, I'm reposting my analysis and request-for-input email that I submitted way back in March. Feedback would be appreciated. The sooner the MMUSIC group can get engaged on this, the sooner we can get it off our collective plate, and the sooner it can be used. --------------------- After talking this over with some of the folks here, it's clear that perhaps that the three-way handshake is the Grand Simplifying Notion(tm). SIP has this property, and to date it is SIP that is the only protocol causing grief with the forking-INVITE. So, my assertion is that forking-INVITE ceases to be a problem if the condition described in section 4 of comedia is defined to be the ACK message from Alice rather than the 200 response from Bob. Taking my earlier forking INVITE example, here's what happens: Alice Proxy Bob Dan Offer -------> Offer ----> | +------------------> <----Answer <---------Answer <------------------Answer Cancel-------------------> CONNECT -------------------> ACK -------------------> By delaying the initiation of the connect-then-answer listed in section 4(b/c) to the transmission of the ACK, we've allowed the fork to collapse back to a pair of endpoints before any connections are initiated. So instead of dealing with the large permutations caused by the 1-to-n fan-out of Alice to possible destinations, we're back to just Alice and Bob (Bob being defined to always be the "winner" of the forked INVITE). With this in mind, there are now five unique scenarios of Alice, Bob, and Carol: 1) FULL CONNECTIVITY (OR BOB CANNOT CONNECT TO ALICE): Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----------------------> ?? ACK -----------------------> <--------CONNECT ===================================== 2) ALICE CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----X ACK -----------------------> <--------CONNECT Hijack! ===================================== 3) ALICE/CAROL CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT--X CONNECT----X ACK -----------------------> <--------CONNECT ?? <-----------------------CONNECT ===================================== 4) CAROL CANNOT CONNECT TO ALICE (OR CAROL/BOB CANNOT CONNECT TO ALICE): Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT-------> CONNECT----------------------> ?? ACK -----------------------> X--CONNECT ===================================== 5) CAROL CANNOT CONNECT TO BOB: Alice Carol Bob Offer ------------------------> <-----------------------Answer CONNECT--X CONNECT----------------------> ACK -----------------------> <--------CONNECT ====================================== So there are two possible problems. The first is #2, where the connection can be hijacked. The second is #5, where the stakes are raised for Alice to choose correctly between the connection to Bob and the connection to Carol. #2 has the same mitigation strategy as before---if Alice is on the public Internet and Bob is not, then Alice should use direction:passive. #5 is trickier, any thoughts are welcomed. Jonathan, you mentioned that there were some permutations of Offer/Answer that may upset this particular apple cart. Now that this has been all laid out, what say you on this topic? At 01:14 PM 3/17/2003, David Yon wrote: >Temporarily flipping to a SIP-centric worldview, wouldn't one answer be to >map comedia section 4 (b/c) to the ACK message from Alice rather than the >OK reply from Bob? This doesn't answer the question for two-way >handshakes, but it seems to for three-way. _______________________________________________ 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