From exim@www1.ietf.org Wed Oct 1 15:00:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28692 for ; Wed, 1 Oct 2003 15:00:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mCo-0003zp-Il for mmusic-archive@odin.ietf.org; Wed, 01 Oct 2003 15:00:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91J09SM015355 for mmusic-archive@odin.ietf.org; Wed, 1 Oct 2003 15:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mCm-0003zY-1J for mmusic-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 15:00: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 OAA28644 for ; Wed, 1 Oct 2003 14:59:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4mCj-0003pU-00 for mmusic-web-archive@ietf.org; Wed, 01 Oct 2003 15:00:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4mCi-0003pR-00 for mmusic-web-archive@ietf.org; Wed, 01 Oct 2003 15:00:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mCg-0003z3-9Y; Wed, 01 Oct 2003 15:00:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mCA-0003wF-6h for mmusic@optimus.ietf.org; Wed, 01 Oct 2003 14:59: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 OAA28628 for ; Wed, 1 Oct 2003 14:59:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4mC5-0003or-00 for mmusic@ietf.org; Wed, 01 Oct 2003 14:59:25 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4mC5-0003oE-00 for mmusic@ietf.org; Wed, 01 Oct 2003 14:59:25 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Oct 2003 12:04:12 -0700 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h91Iwqwn029794; Wed, 1 Oct 2003 11:58:52 -0700 (PDT) Received: from DWINGW2K4 ([10.32.130.47] (may be forged)) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA26634; Wed, 1 Oct 2003 11:58:52 -0700 (PDT) From: "Dan Wing" To: "NAKAMURA, Hidefumi" Cc: "James M. Polk" , "IETF MMUSIC" Subject: RE: [MMUSIC] IPv4 and IPv6 interworking Date: Wed, 1 Oct 2003 11:58:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <20030930132439.11DC.NAKAMURA.HIDEFUMI@lab.ntt.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Thanks, I'll take a look at using that to our advantage with IPv4/v6 interworking. -d > -----Original Message----- > From: NAKAMURA, Hidefumi [mailto:nakamura.hidefumi@lab.ntt.co.jp] > Sent: Monday, September 29, 2003 9:44 PM > To: Dan Wing > Cc: James M. Polk; IETF MMUSIC > Subject: Re: [MMUSIC] IPv4 and IPv6 interworking > > > Hi. > > If you establish a session with SIP, I think RFC3312 mechanism may help > to solve this problem though some extension will be needed. > (and also in case that the SIP messages are exchanged in IPv4 packets) > > RFC3312 describes how to negotiate SDPs between two endpoints without > sending independent INVITE messages twice though it is for the QoS > negotiation. > > > > At 01:14 PM 9/29/2003 -0700, Dan Wing wrote: > > > >Let's say a Alice capable of sourcing/sinking both IPv4 and > > > >IPv6, and Alice > > > >wants to establish a session with Bob. Alice doesn't know, a > > > >priori, if Bob > > > >supports IPv4 or IPv6. Let's also say that Bob only supports IPv4. > > > > > > What's the normal response of an IPv4 device that receives an > > > IPv6 packet? > > > This seems like a good place to start... > > > > Yes, but it didn't receive an IPv6 packet -- it receives a SIP > > packet from its IPv4-only SIP proxy, but the SDP describes an > > IPv6 session. > > > > The normal reaction to an SDP session you can't support is well > > understood. I'm asking if that's all folks expect out of IPv4/ > > IPv6 interworking. > > > > -d > > > > > >Does Alice have to send an Offer with IPv6, have Bob reject the > > > Offer, and > > > >then Alice has to send another Offer for IPv4? > > > > > > > >RFC3266 describes SDP for IPv6, but it appears it isn't possible to > > > >simultaneously offer both IPv4 and IPv6 in SDP. > > > > > > > >-d > > > > > > > > > > > >_______________________________________________ > > > >mmusic mailing list > > > >mmusic@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > > > > cheers, > > > James > > > > > > ******************* > > > Truth is not to be argued... it is to be presented > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > -- > NAKAMURA, Hidefumi > NTT ServiceIntegration /NetworkServiceSystems Labs. > tel: +81(422)59 3904; fax:+81(422)60 4012 > --- > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 1 15:04:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28908 for ; Wed, 1 Oct 2003 15:04:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mGX-00048I-Vc for mmusic-archive@odin.ietf.org; Wed, 01 Oct 2003 15:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91J41am015885 for mmusic-archive@odin.ietf.org; Wed, 1 Oct 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mGX-000488-ST for mmusic-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 15:04: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 PAA28858 for ; Wed, 1 Oct 2003 15:03:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4mGU-0003sJ-00 for mmusic-web-archive@ietf.org; Wed, 01 Oct 2003 15:03:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4mGU-0003sG-00 for mmusic-web-archive@ietf.org; Wed, 01 Oct 2003 15:03:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mGW-00047U-Me; Wed, 01 Oct 2003 15:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4mFh-00046t-V6 for mmusic@optimus.ietf.org; Wed, 01 Oct 2003 15:03: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 PAA28772 for ; Wed, 1 Oct 2003 15:02:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4mFe-0003rX-00 for mmusic@ietf.org; Wed, 01 Oct 2003 15:03:07 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4mFe-0003r6-00 for mmusic@ietf.org; Wed, 01 Oct 2003 15:03:06 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 01 Oct 2003 12:02:23 -0700 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h91J2XJs006902; Wed, 1 Oct 2003 12:02:34 -0700 (PDT) Received: from DWINGW2K4 ([10.32.130.47] (may be forged)) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA04421; Wed, 1 Oct 2003 12:02:33 -0700 (PDT) From: "Dan Wing" To: "Jonathan Rosenberg" Cc: "IETF MMUSIC" Subject: RE: [MMUSIC] IPv4 and IPv6 interworking Date: Wed, 1 Oct 2003 12:02:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3F7928AA.2060001@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 Thanks, Jonathan. -d > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, September 29, 2003 11:55 PM > To: Dan Wing > Cc: IETF MMUSIC > Subject: Re: [MMUSIC] IPv4 and IPv6 interworking > > > The right way to do this is with the alt mechanism: > http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-alt-01.txt > > in concert with ICE: > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-01.txt > > THe alt mechanism allows Alice to tell Bob about both the v4 and v6 > addresses, and the ICE mechanism (which will be revised as an mmusic > work item per the last ietf meeting) allows for connectivity in more > complex cases than the one you describe below. In particular, when > Alice is v6 only and there is a 6to4 nat. > > -Jonathan R. > > Dan Wing wrote: > > > Let's say a Alice capable of sourcing/sinking both IPv4 and > IPv6, and Alice > > wants to establish a session with Bob. Alice doesn't know, a > priori, if Bob > > supports IPv4 or IPv6. Let's also say that Bob only supports IPv4. > > > > Does Alice have to send an Offer with IPv6, have Bob reject the > Offer, and > > then Alice has to send another Offer for IPv4? > > > > RFC3266 describes SDP for IPv6, but it appears it isn't possible to > > simultaneously offer both IPv4 and IPv6 in SDP. > > > > -d > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 2 10:48:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22725 for ; Thu, 2 Oct 2003 10:48:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kU-0003C6-Ps for mmusic-archive@odin.ietf.org; Thu, 02 Oct 2003 10:48:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92EmAp8012272 for mmusic-archive@odin.ietf.org; Thu, 2 Oct 2003 10:48:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kU-0003Br-L8 for mmusic-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:48:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22673 for ; Thu, 2 Oct 2003 10:47:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54kS-0001Rp-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 10:48:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54kR-0001Rj-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 10:48:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54kL-0003AW-HS; Thu, 02 Oct 2003 10:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54js-00038y-KM for mmusic@optimus.ietf.org; Thu, 02 Oct 2003 10:47:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22650 for ; Thu, 2 Oct 2003 10:47:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54jq-0001RJ-00 for mmusic@ietf.org; Thu, 02 Oct 2003 10:47:30 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A54jp-0001RG-00 for mmusic@ietf.org; Thu, 02 Oct 2003 10:47:29 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h92ElRN1009980 for ; Thu, 2 Oct 2003 16:47:27 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6Y2JP3V; Thu, 2 Oct 2003 16:48:42 +0200 Message-ID: <3F7C3A7F.4050107@ericsson.com> Date: Thu, 02 Oct 2003 16:47:27 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Proposal to remove ready-nm state 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 suggested and got support in yesterdays discussion to remove the ready-nm state from the RTSP state machine and the functionality required to make this state work. See below link for further comments on this. http://rtsp.org/bug795295 Unless anyone has any comment about this within a week or so I will start removing it from the text. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 2 10:55:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23621 for ; Thu, 2 Oct 2003 10:55:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54r9-000479-MI for mmusic-archive@odin.ietf.org; Thu, 02 Oct 2003 10:55:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Et3M1015809 for mmusic-archive@odin.ietf.org; Thu, 2 Oct 2003 10:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54r9-00046u-IP for mmusic-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23604 for ; Thu, 2 Oct 2003 10:54:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54r6-0001Z4-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 10:55:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54r6-0001Yz-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 10:55:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54r8-00044z-B7; Thu, 02 Oct 2003 10:55:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54qp-00043g-Ux for mmusic@optimus.ietf.org; Thu, 02 Oct 2003 10:54: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 KAA23557 for ; Thu, 2 Oct 2003 10:54:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54qn-0001YN-00 for mmusic@ietf.org; Thu, 02 Oct 2003 10:54:41 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A54qm-0001YK-00 for mmusic@ietf.org; Thu, 02 Oct 2003 10:54:40 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h92EsdN1012216 for ; Thu, 2 Oct 2003 16:54:39 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6Y2JRBZ; Thu, 2 Oct 2003 16:55:54 +0200 Message-ID: <3F7C3C30.6060906@ericsson.com> Date: Thu, 02 Oct 2003 16:54:40 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Proposal to remove SETUP and TEARDOWN of individual media streams in PLAY state 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, Another issue that was discussed on yesterdays telecon was the removal of the part specifying that usage of setup and teardown on individual media stream in PLAY state is possible. This does not effect the functionality for: - SETUP and Teardown in ready state - The usage of SETUP to change transport parameters. - Usage of aggregated Teardown in play state to end session. The removal of this functionality will be done in such way that it will be possible in the future to specify this as extension functionality. If no comments are received on this within a week I will start making these changes. And comments for keeping this functionality should state a strong use cases for this. See also: http://rtsp.org/bug810666 Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 2 11:03:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24104 for ; Thu, 2 Oct 2003 11:03:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54ys-0004iw-NB for mmusic-archive@odin.ietf.org; Thu, 02 Oct 2003 11:03:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92F3220018152 for mmusic-archive@odin.ietf.org; Thu, 2 Oct 2003 11:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54ys-0004ih-Jq for mmusic-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 11:03: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 LAA24066 for ; Thu, 2 Oct 2003 11:02:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54yp-0001fs-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 11:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54yp-0001fp-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 11:02:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54yr-0004iF-LI; Thu, 02 Oct 2003 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54yO-0004gk-OT for mmusic@optimus.ietf.org; Thu, 02 Oct 2003 11:02: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 LAA24062 for ; Thu, 2 Oct 2003 11:02:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54yM-0001fb-00 for mmusic@ietf.org; Thu, 02 Oct 2003 11:02:30 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A54yL-0001fY-00 for mmusic@ietf.org; Thu, 02 Oct 2003 11:02:29 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h92F2RlN023376 for ; Thu, 2 Oct 2003 17:02:28 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YNQARM; Thu, 2 Oct 2003 17:05:25 +0200 Message-ID: <3F7C3E04.3080204@ericsson.com> Date: Thu, 02 Oct 2003 17:02: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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Lack of aggregated control URI means non-aggregated control 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, In yesterdays telecon the issue around http://rtsp.org/bug640272 was discussed. The remaining issue is if the lack of an aggregated control URI in SDP means that a session "SHOULD" or "SHALL" be setup in non-aggregated control. Both viewpoints was expressed in Vienna and the the discussion needs closure. My personal view is that a SHOULD is sufficient. Therefore I have drafted the below text for the SETUP section of the RTSP draft. The URI rules are based on the ones Aravind drafted. "If an Aggregate control URI is not specified in the session description, it is probably a indication that non-aggregated control should be used. However a client MAY try to SETUP the session in aggregated control. If the server refuse to aggregate the specified media, the server SHALL use the 459 error code. If the server allows the aggregation, then the client MUST create an URI for aggregate control of the session. This URI MUST contain the servers host address and MUST contain the port, if applicable (e.g. not default port). Once an URI is used to refer to an aggregation for a given session, that URI MUST be used to refer to that aggregation for the duration of the session. If the contents of the aggregation change, then a different aggregate control URI SHOULD be used." Please give your comments. Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 2 11:09:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24498 for ; Thu, 2 Oct 2003 11:09:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A554f-0005CA-QE for mmusic-archive@odin.ietf.org; Thu, 02 Oct 2003 11:09:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92F91Q4019961 for mmusic-archive@odin.ietf.org; Thu, 2 Oct 2003 11:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A554f-0005Bs-MZ for mmusic-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 11:09: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 LAA24424 for ; Thu, 2 Oct 2003 11:08:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A554d-0001k0-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 11:08:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A554c-0001jx-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 11:08:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A554e-0005BD-O7; Thu, 02 Oct 2003 11:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A553v-0005AP-3n for mmusic@optimus.ietf.org; Thu, 02 Oct 2003 11:08: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 LAA24404 for ; Thu, 2 Oct 2003 11:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A553s-0001jP-00 for mmusic@ietf.org; Thu, 02 Oct 2003 11:08:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A553r-0001jM-00 for mmusic@ietf.org; Thu, 02 Oct 2003 11:08:11 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h92F89N1015542 for ; Thu, 2 Oct 2003 17:08:10 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6Y2JT5A; Thu, 2 Oct 2003 17:09:24 +0200 Message-ID: <3F7C3F59.8060709@ericsson.com> Date: Thu, 02 Oct 2003 17:08:09 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Synchronization information in regards to changed transport parameters 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, The previous week we had a discussion on the issue if there is meaningful to allow for the possibility to include Range and RTP-Info in SETUP response which changes the transport parameters for a media stream. There where a good use reasons mentioned by Anders Klemets why this information should be present. As of a result of the discussion the below text has been drafted by me. Please review and comment if it is appropriate. "A client {\MAY} 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). Reasons to support changing transport parameters, is to allow for application layer mobility and flexibility to utilize the best available transport as it becomes available. In a {\SETUP} response for a request to change the transport parameters while in Play state, the server {\SHOULD} include the \header{Range} to indicate from what point the new transport parameters are used. Further if RTP is used for delivery the server {\SHOULD} also include the \header{RTP-Info} header to indicate from what timestamp and RTP sequence number the change has taken place. If both \header{RTP-Info} and \header{Range} is included in the response the "rtp\_time" parameter and range {\MUST} be for the corresponding time, i.e. be used in the same way as for {\PLAY} to ensure the correct synchronization information is present. If the transport parameter change while in play state results in a change of synchronization related information, for example changing RTP SSRC, the server {\MUST} provide in the {\SETUP} response the necessary synchronization information. However the server is {\RECOMMENDED} to avoid changing the synchronization information if possible." Best Regards Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 2 12:24:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29285 for ; Thu, 2 Oct 2003 12:24:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56FJ-0001kz-3f for mmusic-archive@odin.ietf.org; Thu, 02 Oct 2003 12:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92GO4qD006746 for mmusic-archive@odin.ietf.org; Thu, 2 Oct 2003 12:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56FI-0001kj-Mf for mmusic-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 12:24: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 MAA29275 for ; Thu, 2 Oct 2003 12:23:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56FH-00037d-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 12:24:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A56FG-00037a-00 for mmusic-web-archive@ietf.org; Thu, 02 Oct 2003 12:24:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56FE-0001kG-S9; Thu, 02 Oct 2003 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A56EU-0001jY-Ns for mmusic@optimus.ietf.org; Thu, 02 Oct 2003 12:23: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 MAA29231 for ; Thu, 2 Oct 2003 12:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A56ER-00036z-00 for mmusic@ietf.org; Thu, 02 Oct 2003 12:23:11 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1A56ER-00036w-00 for mmusic@ietf.org; Thu, 02 Oct 2003 12:23:11 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1A56EK-0000R0-00; Thu, 02 Oct 2003 09:23:04 -0700 Date: Thu, 2 Oct 2003 09:23:04 -0700 From: Tom Marshall To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Proposal to remove SETUP and TEARDOWN of individual media streams in PLAY state Message-ID: <20031002162304.GA1555@real.com> References: <3F7C3C30.6060906@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IJpNTDwzlM2Ie8A6" Content-Disposition: inline In-Reply-To: <3F7C3C30.6060906@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Together with the removal of ready-nm state, does mean that a successful TEARDOWN always deletes the session? On Thu, Oct 02, 2003 at 04:54:40PM +0200, Magnus Westerlund wrote: > Hi, >=20 > Another issue that was discussed on yesterdays telecon was the removal=20 > of the part specifying that usage of setup and teardown on individual=20 > media stream in PLAY state is possible. This does not effect the=20 > functionality for: >=20 > - SETUP and Teardown in ready state > - The usage of SETUP to change transport parameters. > - Usage of aggregated Teardown in play state to end session. >=20 > The removal of this functionality will be done in such way that it will= =20 > be possible in the future to specify this as extension functionality. >=20 > If no comments are received on this within a week I will start making=20 > these changes. And comments for keeping this functionality should state= =20 > a strong use cases for this. >=20 > See also: > http://rtsp.org/bug810666 >=20 > Best Regards >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 --=20 A revised schedule is to business what a new season is to an athlete or a new canvas to an artist. -- Norman Augustine --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fFDoqznSmcYu2m8RAhMiAJ9xiJ09TfVMzMLBUqD63xDNskGqtwCfWndF wh+35LediNuf+781Bq46bdc= =FDUf -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 3 02:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24515 for ; Fri, 3 Oct 2003 02:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JiS-0006wK-GI for mmusic-archive@odin.ietf.org; Fri, 03 Oct 2003 02:47:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h936l4Cg026670 for mmusic-archive@odin.ietf.org; Fri, 3 Oct 2003 02:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JiS-0006w5-4O for mmusic-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 02:47: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 CAA24507 for ; Fri, 3 Oct 2003 02:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5JiO-0004Si-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 02:47:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5JiN-0004Sf-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 02:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5JiQ-0006ve-8Y; Fri, 03 Oct 2003 02:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Ji4-0006uj-Sn for mmusic@optimus.ietf.org; Fri, 03 Oct 2003 02:46: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 CAA24490 for ; Fri, 3 Oct 2003 02:46:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ji0-0004SN-00 for mmusic@ietf.org; Fri, 03 Oct 2003 02:46:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5Ji0-0004SK-00 for mmusic@ietf.org; Fri, 03 Oct 2003 02:46:36 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h936kXN1026070; Fri, 3 Oct 2003 08:46:37 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6Y2NSFP; Fri, 3 Oct 2003 08:47:50 +0200 Message-ID: <3F7D1B48.2090203@ericsson.com> Date: Fri, 03 Oct 2003 08:46:32 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Proposal to remove SETUP and TEARDOWN of indiv idual media streams in PLAY state References: <20031002162304.GA1555@real.com> In-Reply-To: <20031002162304.GA1555@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 No, Not if you do teardown on a individual stream in Ready state for a session with more than one media. Tom Marshall wrote: > Together with the removal of ready-nm state, does mean that a successful > TEARDOWN always deletes the session? > Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 3 09:57:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07234 for ; Fri, 3 Oct 2003 09:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5QQZ-0006yQ-Qr for mmusic-archive@odin.ietf.org; Fri, 03 Oct 2003 09:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Dv3jx026800 for mmusic-archive@odin.ietf.org; Fri, 3 Oct 2003 09:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5QQZ-0006yB-Im for mmusic-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 09:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07217 for ; Fri, 3 Oct 2003 09:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5QQX-00016G-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 09:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5QQX-00016D-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 09:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5QQX-0006xf-BV; Fri, 03 Oct 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5QQL-0006w1-1m for mmusic@optimus.ietf.org; Fri, 03 Oct 2003 09:56: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 JAA07207 for ; Fri, 3 Oct 2003 09:56:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5QQI-000163-00 for mmusic@ietf.org; Fri, 03 Oct 2003 09:56:46 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1A5QQH-00015u-00 for mmusic@ietf.org; Fri, 03 Oct 2003 09:56:46 -0400 Received: from phys-ha2mpka.Eng.Sun.COM ([129.146.16.21]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h93DuiaV020192 for ; Fri, 3 Oct 2003 07:56:44 -0600 (MDT) Received: from sun.com (vpn-129-150-18-168.SFBay.Sun.COM [129.150.18.168]) by phys-ha2mpka.Eng.Sun.COM (8.8.8p2+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id GAA03360 for ; Fri, 3 Oct 2003 06:56:43 -0700 (PDT) Message-ID: <3F7D7F98.8070004@sun.com> Date: Fri, 03 Oct 2003 09:54:32 -0400 From: Aravind Narasimhan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030529 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 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Notes for 10/01/03 RTSP Telecon 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 Meeting Notes for 10/01 RTSP Concall Attendees: Magnus Westerlund Thomas Zeng Aravind Narasimhan Greg Sherwood Colin Perkins Sean Sheedy Detailed Minutes: Thomas: Working on strawman draft for End of Stream Sean: Filed end of stream 2 bug years ago. Magnus: In feature request area. Magnus: 3.a. Range header bug. We have text, Let's close Magnus: 3.b. PAUSE in ready state. Magnus: Text available in bis04. Any controversy? Take it to list Magnus 3.c. Multiple SSRC. Let's close Aravind: has been through multiple iterations in meetings and spec. Magnus: 3.d. RTP timestamp and pause Aravind: There is text in 3GPP. Magnus: I proof read it. It should be good. But we need a good example in the RTSP Spec. Magnus: 3.e. "a=range" is missing IANA registration Magnus: Has been written up. Can be closed. Please review text in bis04 Magnus: 3.f. PLAY at end of media Magnus: Written up this month. Needs to be reviewed. Magnus: 3.g: Implicit REDIRECT Magnus: Resolution in Vienna was a new 300 redirect code so that if you understand the SDP and 300 code you can go immediately to the new server and use the SDP. If you dont understand the code then just redirect and do an describe. Greg: Sounds good. Vienna Discussion Items: Colin Joined the call. Magnus: 3.h. Aggregate URL discussion Magnus: Session declarations lacking a session level control URL, SHOULD be used in non-aggregated control. Aravind: The main issue is what the rules are for generating the aggregate control URL. Magnus: The wording proposed to have client create aggregate control URI in the current text is good. Aravind: I belive Bill May had an issue with this. Not sure if it is resolved. Magnus: Will post to the mailing list the proposed wording. Magnus: I think the rules available which Aravind wrote into bis04 are acceptable. But lets resolve this when I post to the mailing list the new SETUP text. Magnus: 3.i. a=range in SDP to indicate live media Magnus: Has been adopted in 3GPP. I added the wording to CVS. Thomas: I dont see any problems with it Magnus: 3.j. How does REDIRECT method work Magnus: Sessions will be terminated by successful REDIRECT Thomas: I dont object to this. But I want to point out that this is the only server -> client request that changes state Thomas: The spirit of not requiring TEARDOWN after redirect is that the server can get rid of the session. By having the client doing a teardown the cleint maintains control of the state machine Magnus: It doesn't make sense to have the client send TEARDOWN when the server needs to go away Greg: If the server wants to drop the session but do it intelligently, it can do so by doing a REDIRECT without location header which basically indicates to the client that the server is going away. Greg: Is it ok for the server to close the connecting when it sends a REDIRECT? Magnus: Connection:close can't be put into work until the complete transaction is performed. In other words the response must be sent before closing the TCP connection. Greg: The situation where a server would send a REDIRECT is where the server would have to go down in short order. So it may want to close the connection. Thomas: Why don't we do that instead of having a redirect always imply a teardown. Magnus: After the client answers RTSP 200 Ok, that can have connection close header. Thomas: Does the server still stay around to get 200 ok. Greg: The server may send the connection close header and may not do anything else and my not stay around for the response. Thomas: If the server needs to go away then this wont work. Greg: In the case where the server has to go away the server should wait for the 200k but it is just a courtesy to the client. Magnus: There are other considerations especially with proxies in the middle. If there are multiple sessions over a single TCP conneciton. Thomas: Isnt there a way to do a REDIRECT with out a session header which tells the server that all the session are going away. That will take care of this concern. Greg: Please clarify the proxy issue. It is just replicating the connections to the server, no? Magnus: 1 TCP connection from proxy to server may be handling multiple sessions. Magnus: Any volunteers to write up? No. Leave it waiting. Magnus: 3.k Indicating end of stream Thomas: End of stream strawman draft is almost done. Sean: We had a proposal 2 years back based on the way we did it. It was a hack based on ANNOUCE, but there are bits of information that the client wants. Will Send to thomas for him to incoporate in to his write up Mangus: Client will want to know sequence number of the last packet on the stream. Thomas: Specific to RTP-Info: The BNF does allow one of rtptime or seqnum, or both, so for response to END_OF_STREAM just seqnum is enough to tell client what is the ending packet. Magnus: Take discussion to mailing list. Magnus: 3.m Request to response time is not limited. Magnus: Response time limit for requests. There is no indication in spec right now. Was pointed out by SIP folks. Sean: Would like to second that. Nobody is willing to wait for an arbitrary amount of time for a response in order to retry. 10 seconsds seems reasonable. Thomas: We need a header parameter in the client request indicating how long the it is going to wait. Sean: If the client sends a request a server, how long should it wait? Sean: Should just have a resonable value. Thomas: Do you see an issue in having the client send a parameter indicating client time out? Sean: Too complicated. Greg: Is there already a precedence for this in SIP? Magnus: Had an impression that there is something is SIP. Collin: It wouldn't surprise me if SIP has it. But it may not be the same thing that is useful for RTSP. Thomas: It is the client that knows what it wants to expect. And since the server can tell the client of timeout, why not have client do it to server. Magnus: 10 seconds should be enough for all purposes here. Greg: The server must respond in 10 seconds? Thomas: or send 100 response saying I'm working on it. Greg: What if the client pipelines hundereds of requests all at the same time? Collin: There are trasnmission delays. Can only deal with this with Timestamps. Magnus: The requester waits up to 10 second. The responder must answer within 5 seconds. That way some numbers on transport delay is present. Thomas: 10 seconds without regard to TCP delays. Collin: Does the spec have a section with discussion when it is appropriate to pipeline commands. Thomas: There is no congestions control dicussion on pipeline. Magnus: You can pipline n setups, multiple non-aggregated plays or pause, OPTIONS and DESCRIBE. Thomas: Need to handle congestion control too. . . Collin: One is cogestgion, the other is that it is going to take a long time Sean: If the server knows it needs to do some serious processing, then it will send a 100 response. If no 100 reponse it sent, then there is a congestion problem somewhere Sean: Will attempt to write this up Magnus: 3.n. Version number Mangus: Aravind is taking a look at the spec for change Aravind: I am cataloging the spec for changes so that we can have a good understanding of the scope of the changes. IT was clear at the Vienna meeting that we did not have a good handle on this. Should have a preliminary list by sometime next week. Magnus: 4.a TEARDOWN using * and the Ready-nm state. Magnus: No need to keep this complication in the state machine. If you have no media in your session, your session is gone. Greg: Why was this added: Magnus: Added a year ago. It was mainly to preserve some resources on the server side. But this seems less useful now. Aravind: Agreed. Thomas: Leaving it in will require more error handling. What happens when you do PLAY on a Ready-nm state? Mangus: Let's remove this state Aravind: It complicates the state machine for the normal case. Magnus: I will mail the question to the mailing list before removing it Magnus: 4.b. How to handle sync in re-SETUP Magnus: Will use Range and RTP-Info for syncing after RESETUP. Will post to list. Magnus: 4.c. Re-SETUP of transport parameters Magnus: There was discussion on the mailing list. Geetha agreed to write it up. Magnus: 4.d. Removal of SETUP in play state Magnus: SETUP in play state will be removed from the core spec and will post a mailing list. It is better to leave this as an extension. Thomas: Yes it works better as an extension with the stream switching stuff. Aravind: Let's remove it, but let's make sure that we don't make it hard to add as an extension. Magnus: Next Meeting will be Tuesday, October 14th. That will give use a week and half to finish up changes to the spec for the November meeting. Magnus: October 27th is the deadline for submission to November IETF meeting. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 3 10:14:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08790 for ; Fri, 3 Oct 2003 10:14:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Qh0-0007qK-3y for mmusic-archive@odin.ietf.org; Fri, 03 Oct 2003 10:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93EE2dL030142 for mmusic-archive@odin.ietf.org; Fri, 3 Oct 2003 10:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Qh0-0007q5-0n for mmusic-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 10:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08738 for ; Fri, 3 Oct 2003 10:13:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5Qgx-0001Jf-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 10:13:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5Qgx-0001Jc-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 10:13:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5Qgy-0007pe-Sm; Fri, 03 Oct 2003 10:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5QgV-0007p3-NH for mmusic@optimus.ietf.org; Fri, 03 Oct 2003 10:13: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 KAA08668 for ; Fri, 3 Oct 2003 10:13:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5QgT-0001JB-00 for mmusic@ietf.org; Fri, 03 Oct 2003 10:13:29 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A5QgS-0001J8-00 for mmusic@ietf.org; Fri, 03 Oct 2003 10:13:28 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h93EDRN1006336 for ; Fri, 3 Oct 2003 16:13:27 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6YNX4F8; Fri, 3 Oct 2003 16:16:29 +0200 Message-ID: <3F7D8405.6000101@ericsson.com> Date: Fri, 03 Oct 2003 16:13:25 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Lack of aggregated control URI means non-aggregated control References: <3F7C3E04.3080204@ericsson.com> In-Reply-To: <3F7C3E04.3080204@ericsson.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 got a comment that made me aware of the inappropriateness in my view of the last sentence in the below text, i.e. "If the contents of the aggregation change, then a different aggregate control URI SHOULD be used.". This sentence is not clear what it means. I think it is much simpler and clearer to simply require the client and server to continue to use the created URI for this session. Therefore I propose to remove the last sentence. Best Regards Magnus Magnus Westerlund wrote: > Hi, > > In yesterdays telecon the issue around http://rtsp.org/bug640272 > was discussed. The remaining issue is if the lack of an aggregated > control URI in SDP means that a session "SHOULD" or "SHALL" be setup in > non-aggregated control. Both viewpoints was expressed in Vienna and the > the discussion needs closure. My personal view is that a SHOULD is > sufficient. Therefore I have drafted the below text for the SETUP > section of the RTSP draft. The URI rules are based on the ones Aravind > drafted. > > "If an Aggregate control URI is not specified in the session > description, it is probably a indication that non-aggregated > control should be used. However a client MAY try to SETUP the > session in aggregated control. If the server refuse to aggregate > the specified media, the server SHALL use the 459 error code. > If the server allows the aggregation, then the client MUST > create an URI for aggregate control of the session. This URI > MUST contain the servers host address and MUST contain the > port, if applicable (e.g. not default port). Once an URI is used > to refer to an aggregation for a given session, that URI MUST > be used to refer to that aggregation for the duration of the > session. If the contents of the aggregation change, then a > different aggregate control URI SHOULD be used." > > Please give your comments. > > Best Regards > > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 3 12:56:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16468 for ; Fri, 3 Oct 2003 12:56:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TDo-0008PH-Kf for mmusic-archive@odin.ietf.org; Fri, 03 Oct 2003 12:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Gu4eb032316 for mmusic-archive@odin.ietf.org; Fri, 3 Oct 2003 12:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TDo-0008P9-F6 for mmusic-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 12:56: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 MAA16453 for ; Fri, 3 Oct 2003 12:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5TDm-0003eu-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 12:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5TDm-0003eq-00 for mmusic-web-archive@ietf.org; Fri, 03 Oct 2003 12:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TDm-0008Og-AT; Fri, 03 Oct 2003 12:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5TDO-0008Nx-6e for mmusic@optimus.ietf.org; Fri, 03 Oct 2003 12:55: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 MAA16433 for ; Fri, 3 Oct 2003 12:55:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5TDM-0003eR-00 for mmusic@ietf.org; Fri, 03 Oct 2003 12:55:36 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1A5TDL-0003eI-00 for mmusic@ietf.org; Fri, 03 Oct 2003 12:55:35 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1A5TDF-0002ZU-00; Fri, 03 Oct 2003 09:55:29 -0700 Date: Fri, 3 Oct 2003 09:55:29 -0700 From: Tom Marshall To: Aravind Narasimhan Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Notes for 10/01/03 RTSP Telecon Message-ID: <20031003165529.GA9816@real.com> References: <3F7D7F98.8070004@sun.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: <3F7D7F98.8070004@sun.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I still don't recall anyone explaining why this is an issue.=20 Implementations are free to "give up" at any point and, of course, the end-user ultimately should decide the acceptable delay. I think the most sensible way to handle this is to recommend that clients have a default timeout of X seconds (I would say X no smaller than 60 but that's me) and the timeout should (must?) be configurable by the user. The reason I'm so opposed to this idea is that RTSP runs on top of TCP. TCP can, and does, mitigate packet loss with retransmissions. You cannot assume that just because the client sent a request at time T, the server received it at (T+RTT/2), and likewise for the server's response. I've personally run into high loss networks where responses were delayed for much longer than 10 seconds due to retransmissions but still wanted the content enough to wait. I've also run into physical layer problems (disconnected network cable, timed out VPN) where correcting the problem allowed the TCP connection to continue smoothly. I don't think we should gratuitously break the RTSP layer sooner than the TCP layer gives up or try to second guess the TCP layer, especially since RTSP above TCP in the stack. > Magnus: 3.m Request to response time is not limited. > Magnus: Response time limit for requests. There is no indication in > spec right now. Was pointed out by SIP folks. > Sean: Would like to second that. Nobody is willing to wait for an > arbitrary amount of time for a response in order to retry. 10 seconsds > seems reasonable. > Thomas: We need a header parameter in the client request indicating how > long the it is going to wait. > Sean: If the client sends a request a server, how long should it wait? > Sean: Should just have a resonable value. > Thomas: Do you see an issue in having the client send a parameter > indicating client time out? > Sean: Too complicated. > Greg: Is there already a precedence for this in SIP? > Magnus: Had an impression that there is something is SIP. > Collin: It wouldn't surprise me if SIP has it. But it may not be the > same thing that is useful for RTSP. > Thomas: It is the client that knows what it wants to expect. And since > the server can tell the client of timeout, why not have client do it to > server. > Magnus: 10 seconds should be enough for all purposes here. > Greg: The server must respond in 10 seconds? > Thomas: or send 100 response saying I'm working on it. > Greg: What if the client pipelines hundereds of requests all at the > same time? > Collin: There are trasnmission delays. Can only deal with this with > Timestamps. > Magnus: The requester waits up to 10 second. The responder must answer > within 5 seconds. That way some numbers on transport delay is present. > Thomas: 10 seconds without regard to TCP delays. > Collin: Does the spec have a section with discussion when it is > appropriate to pipeline commands. > Thomas: There is no congestions control dicussion on pipeline. > Magnus: You can pipline n setups, multiple non-aggregated plays or > pause, OPTIONS and DESCRIBE. > Thomas: Need to handle congestion control too. . . > Collin: One is cogestgion, the other is that it is going to take a long > time > Sean: If the server knows it needs to do some serious processing, > then it will send a 100 response. If no 100 reponse it sent, then there > is a congestion problem somewhere > Sean: Will attempt to write this up --=20 One good reason why computers can do more work than people is that they never have to stop and answer the phone. --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/faoBqznSmcYu2m8RAg8QAJ4leC2ckvMZF6Dq5Dgk/0L812DPgACcCnAj UE/Aq84MlpYvVFfFU78mIbw= =G5qL -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 6 03:29:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20489 for ; Mon, 6 Oct 2003 03:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pno-00013q-Gw for mmusic-archive@odin.ietf.org; Mon, 06 Oct 2003 03:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h967T8Pb004078 for mmusic-archive@odin.ietf.org; Mon, 6 Oct 2003 03:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pnn-00013h-PZ for mmusic-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 03:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20485 for ; Mon, 6 Oct 2003 03:28:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6Pnl-0001sS-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 03:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6Pnk-0001sO-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 03:29:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6Pni-00013B-4w; Mon, 06 Oct 2003 03:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6PnN-00012k-1k for mmusic@optimus.ietf.org; Mon, 06 Oct 2003 03:28: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 DAA20479 for ; Mon, 6 Oct 2003 03:28:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6PnK-0001sL-00 for mmusic@ietf.org; Mon, 06 Oct 2003 03:28:38 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A6PnJ-0001sI-00 for mmusic@ietf.org; Mon, 06 Oct 2003 03:28:37 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h967SblN020173; Mon, 6 Oct 2003 09:28:37 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id T6Y20WL8; Mon, 6 Oct 2003 09:30:05 +0200 Message-ID: <3F81199C.2060508@ericsson.com> Date: Mon, 06 Oct 2003 09:28: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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: mmusic@ietf.org Subject: Re: [MMUSIC] Notes for 10/01/03 RTSP Telecon References: <20031003165529.GA9816@real.com> In-Reply-To: <20031003165529.GA9816@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, I understand your concerns regarding TCP, and I think your reasoning is valid for this part of the problem. The other part is how long a server should maximum wait before using a 1xx response code to indicate is the other part. This problem arise for example when doing setup and the time to get the load the media can be of more than a few seconds, for example due to a tape robot. In these scenarios it is good to have a time limit that tells you how long you are at maximum are allowed to delay responding without giving any indication that the request is received. Of course in the tape robot example if the server knows that this is a tape robot it could usually send a 1xx response directly after requesting the media to be loaded. The client side is still a problem. I guess that one needs to write some recommendations on how the client should behave. Having a server side limit allow the client to form opinion on lowest possible delay before time-out. Another interesting problem is with proxies. In this case the transmission of the request to the proxy goes fast and fine. Then when the proxy tries to contact the server the TCP connection takes an long time. How long should the client in this case wait? Another question: For HTTP and SIP after sending a 1xx response, with what time period must the server repeat this message during the wait for the real response? In conclusion: There are some considerations to make in this area. - I think a server side time-out to send a 1xx response is good. - I think that we must resolve also how the client is recommended to behave. This will always be a implementation thing, but guidelines I think is good. Please continue the discussion. Cheers Magnus Tom Marshall wrote: > I still don't recall anyone explaining why this is an issue. > Implementations are free to "give up" at any point and, of course, the > end-user ultimately should decide the acceptable delay. I think the > most > sensible way to handle this is to recommend that clients have a default > timeout of X seconds (I would say X no smaller than 60 but that's me) > and > the timeout should (must?) be configurable by the user. > > The reason I'm so opposed to this idea is that RTSP runs on top of TCP. > TCP > can, and does, mitigate packet loss with retransmissions. You cannot > assume > that just because the client sent a request at time T, the server > received > it at (T+RTT/2), and likewise for the server's response. I've > personally > run into high loss networks where responses were delayed for much longer > than 10 seconds due to retransmissions but still wanted the content > enough > to wait. I've also run into physical layer problems (disconnected > network > cable, timed out VPN) where correcting the problem allowed the TCP > connection to continue smoothly. I don't think we should gratuitously > break > the RTSP layer sooner than the TCP layer gives up or try to second guess > the > TCP layer, especially since RTSP above TCP in the stack. > > >>Magnus: 3.m Request to response time is not limited. >>Magnus: Response time limit for requests. There is no indication in >>spec right now. Was pointed out by SIP folks. >>Sean: Would like to second that. Nobody is willing to wait for an >>arbitrary amount of time for a response in order to retry. 10 > > seconsds > >>seems reasonable. >>Thomas: We need a header parameter in the client request indicating > > how > >>long the it is going to wait. >>Sean: If the client sends a request a server, how long should it > > wait? > >>Sean: Should just have a resonable value. >>Thomas: Do you see an issue in having the client send a parameter >>indicating client time out? >>Sean: Too complicated. >>Greg: Is there already a precedence for this in SIP? >>Magnus: Had an impression that there is something is SIP. >>Collin: It wouldn't surprise me if SIP has it. But it may not be the >>same thing that is useful for RTSP. >>Thomas: It is the client that knows what it wants to expect. And > > since > >>the server can tell the client of timeout, why not have client do it > > to > >>server. >>Magnus: 10 seconds should be enough for all purposes here. >>Greg: The server must respond in 10 seconds? >>Thomas: or send 100 response saying I'm working on it. >>Greg: What if the client pipelines hundereds of requests all at the >>same time? >>Collin: There are trasnmission delays. Can only deal with this with >>Timestamps. >>Magnus: The requester waits up to 10 second. The responder must > > answer > >>within 5 seconds. That way some numbers on transport delay is present. >>Thomas: 10 seconds without regard to TCP delays. >>Collin: Does the spec have a section with discussion when it is >>appropriate to pipeline commands. >>Thomas: There is no congestions control dicussion on pipeline. >>Magnus: You can pipline n setups, multiple non-aggregated plays or >>pause, OPTIONS and DESCRIBE. >>Thomas: Need to handle congestion control too. . . >>Collin: One is cogestgion, the other is that it is going to take a > > long > >>time >>Sean: If the server knows it needs to do some serious processing, >>then it will send a 100 response. If no 100 reponse it sent, then > > there > >>is a congestion problem somewhere >>Sean: Will attempt to write this up > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 6 16:44:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21632 for ; Mon, 6 Oct 2003 16:44:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cDA-0000FM-U7 for mmusic-archive@odin.ietf.org; Mon, 06 Oct 2003 16:44:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96Ki888000941 for mmusic-archive@odin.ietf.org; Mon, 6 Oct 2003 16:44:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cDA-0000F6-QZ for mmusic-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 16:44: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 QAA21594 for ; Mon, 6 Oct 2003 16:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6cD8-0003ZU-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 16:44:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6cD8-0003ZR-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 16:44:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cD3-0000EB-31; Mon, 06 Oct 2003 16:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cCC-0000C2-Kn for mmusic@optimus.ietf.org; Mon, 06 Oct 2003 16:43: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 QAA21417 for ; Mon, 6 Oct 2003 16:42:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6c4B-0003NU-00 for mmusic@ietf.org; Mon, 06 Oct 2003 16:34:51 -0400 Received: from db1.ncube.com ([134.242.64.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6boz-0003E1-00 for mmusic@ietf.org; Mon, 06 Oct 2003 16:19:10 -0400 Received: from warthog.ncube.com (IDENT:dS6dSsvPp1bfCldreiyQa788S+M/b53H@warthog [134.242.65.56]) by db1.ncube.com (8.12.9/8.12.9) with ESMTP id h96KIFip014984; Mon, 6 Oct 2003 13:18:15 -0700 (PDT) Subject: Re: [MMUSIC] Notes for 10/01/03 RTSP Telecon From: Sean Sheedy To: Magnus Westerlund Cc: Tom Marshall , mmusic@ietf.org In-Reply-To: <3F81199C.2060508@ericsson.com> References: <20031003165529.GA9816@real.com> <3F81199C.2060508@ericsson.com> Content-Type: text/plain Organization: nCube Corporation Message-Id: <1065471494.23901.42.camel@warthog.ncube.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-5) Date: 06 Oct 2003 13:18:15 -0700 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 basically agree with Magnus. Relying on TCP alone is not sufficient. Although it will provide reliability to the control connection itself, it's incapable of handling other congestion or failure events outside of the IP domain. For example: * Delays in the server's authentication and billing back end. * Server failures which still allow incoming requests from the IP stack, but which prevent the server from processing the requests in any useful way. Clients need some guidance about the expected response time of the server to be able to detect these types of failures and deal with them appropriately. At the least, it's more user-friendly to be able to say "The server is not responding" than to simply wait for the user to give up in frustration. In practice, every client software author I've worked with has wanted to know the maximum response time of the server. I think discussing the issue in the specification and coming up with some guidelines is better for interoperability than leaving it entirely up to each implementor. Sean On Mon, 2003-10-06 at 00:28, Magnus Westerlund wrote: > Hi Tom, > > I understand your concerns regarding TCP, and I think your reasoning is > valid for this part of the problem. The other part is how long a server > should maximum wait before using a 1xx response code to indicate is the > other part. This problem arise for example when doing setup and the time > to get the load the media can be of more than a few seconds, for example > due to a tape robot. > > In these scenarios it is good to have a time limit that tells you how > long you are at maximum are allowed to delay responding without giving > any indication that the request is received. Of course in the tape robot > example if the server knows that this is a tape robot it could usually > send a 1xx response directly after requesting the media to be loaded. > > The client side is still a problem. I guess that one needs to write some > recommendations on how the client should behave. Having a server side > limit allow the client to form opinion on lowest possible delay before > time-out. > > Another interesting problem is with proxies. In this case the > transmission of the request to the proxy goes fast and fine. Then when > the proxy tries to contact the server the TCP connection takes an long > time. How long should the client in this case wait? > > Another question: For HTTP and SIP after sending a 1xx response, with > what time period must the server repeat this message during the wait for > the real response? > > In conclusion: There are some considerations to make in this area. > > - I think a server side time-out to send a 1xx response is good. > > - I think that we must resolve also how the client is recommended to > behave. This will always be a implementation thing, but guidelines I > think is good. > > Please continue the discussion. > > Cheers > > Magnus > > Tom Marshall wrote: > > > I still don't recall anyone explaining why this is an issue. > > Implementations are free to "give up" at any point and, of course, the > > end-user ultimately should decide the acceptable delay. I think the > > most > > sensible way to handle this is to recommend that clients have a default > > timeout of X seconds (I would say X no smaller than 60 but that's me) > > and > > the timeout should (must?) be configurable by the user. > > > > The reason I'm so opposed to this idea is that RTSP runs on top of TCP. > > TCP > > can, and does, mitigate packet loss with retransmissions. You cannot > > assume > > that just because the client sent a request at time T, the server > > received > > it at (T+RTT/2), and likewise for the server's response. I've > > personally > > run into high loss networks where responses were delayed for much longer > > than 10 seconds due to retransmissions but still wanted the content > > enough > > to wait. I've also run into physical layer problems (disconnected > > network > > cable, timed out VPN) where correcting the problem allowed the TCP > > connection to continue smoothly. I don't think we should gratuitously > > break > > the RTSP layer sooner than the TCP layer gives up or try to second guess > > the > > TCP layer, especially since RTSP above TCP in the stack. > > > > > >>Magnus: 3.m Request to response time is not limited. > >>Magnus: Response time limit for requests. There is no indication in > >>spec right now. Was pointed out by SIP folks. > >>Sean: Would like to second that. Nobody is willing to wait for an > >>arbitrary amount of time for a response in order to retry. 10 > > > > seconsds > > > >>seems reasonable. > >>Thomas: We need a header parameter in the client request indicating > > > > how > > > >>long the it is going to wait. > >>Sean: If the client sends a request a server, how long should it > > > > wait? > > > >>Sean: Should just have a resonable value. > >>Thomas: Do you see an issue in having the client send a parameter > >>indicating client time out? > >>Sean: Too complicated. > >>Greg: Is there already a precedence for this in SIP? > >>Magnus: Had an impression that there is something is SIP. > >>Collin: It wouldn't surprise me if SIP has it. But it may not be the > >>same thing that is useful for RTSP. > >>Thomas: It is the client that knows what it wants to expect. And > > > > since > > > >>the server can tell the client of timeout, why not have client do it > > > > to > > > >>server. > >>Magnus: 10 seconds should be enough for all purposes here. > >>Greg: The server must respond in 10 seconds? > >>Thomas: or send 100 response saying I'm working on it. > >>Greg: What if the client pipelines hundereds of requests all at the > >>same time? > >>Collin: There are trasnmission delays. Can only deal with this with > >>Timestamps. > >>Magnus: The requester waits up to 10 second. The responder must > > > > answer > > > >>within 5 seconds. That way some numbers on transport delay is present. > >>Thomas: 10 seconds without regard to TCP delays. > >>Collin: Does the spec have a section with discussion when it is > >>appropriate to pipeline commands. > >>Thomas: There is no congestions control dicussion on pipeline. > >>Magnus: You can pipline n setups, multiple non-aggregated plays or > >>pause, OPTIONS and DESCRIBE. > >>Thomas: Need to handle congestion control too. . . > >>Collin: One is cogestgion, the other is that it is going to take a > > > > long > > > >>time > >>Sean: If the server knows it needs to do some serious processing, > >>then it will send a 100 response. If no 100 reponse it sent, then > > > > there > > > >>is a congestion problem somewhere > >>Sean: Will attempt to write this up > > > > -- Sean Sheedy seans@ncube.com (503) 531-6427 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 6 17:24:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23655 for ; Mon, 6 Oct 2003 17:24:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cpn-00027i-UM for mmusic-archive@odin.ietf.org; Mon, 06 Oct 2003 17:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h96LO3vN008159 for mmusic-archive@odin.ietf.org; Mon, 6 Oct 2003 17:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cpn-00027V-Ow for mmusic-web-archive@optimus.ietf.org; Mon, 06 Oct 2003 17:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23638 for ; Mon, 6 Oct 2003 17:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6cpl-0004UI-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 17:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6cpk-0004U1-00 for mmusic-web-archive@ietf.org; Mon, 06 Oct 2003 17:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cpl-00026P-4c; Mon, 06 Oct 2003 17:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6cp3-000222-4v for mmusic@optimus.ietf.org; Mon, 06 Oct 2003 17:23: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 RAA23370 for ; Mon, 6 Oct 2003 17:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6cms-0004B3-01 for mmusic@ietf.org; Mon, 06 Oct 2003 17:21:02 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1A6ciV-0004AA-00 for mmusic@ietf.org; Mon, 06 Oct 2003 17:16:31 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1A6ciG-0004Ml-00; Mon, 06 Oct 2003 14:16:16 -0700 Date: Mon, 6 Oct 2003 14:16:16 -0700 From: Tom Marshall To: Sean Sheedy Cc: Magnus Westerlund , mmusic@ietf.org Subject: Re: [MMUSIC] Notes for 10/01/03 RTSP Telecon Message-ID: <20031006211616.GA16578@real.com> References: <20031003165529.GA9816@real.com> <3F81199C.2060508@ericsson.com> <1065471494.23901.42.camel@warthog.ncube.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <1065471494.23901.42.camel@warthog.ncube.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 06, 2003 at 01:18:15PM -0700, Sean Sheedy wrote: > I basically agree with Magnus. >=20 > Relying on TCP alone is not sufficient. Although it will provide > reliability to the control connection itself, it's incapable of handling > other congestion or failure events outside of the IP domain. For > example: > * Delays in the server's authentication and billing back end. > * Server failures which still allow incoming requests from the IP > stack, but which prevent the server from processing the requests > in any useful way. While I agree in principle that a method of handling delays is desirable, I strongly suggest using _only_ positive feedback (1xx responses). I want to ensure that it's crystal clear that negative feedback (no response) is _not_ an indication of failure. Just about every network application I know about allows the TCP layer to do its job without imposing arbitrary time limits on responses. Try unplugging your network cable and running various programs that use TCP sockets to see how long they take to fail. The applications that do impose arbitrary time limits (our player is one) have configurable limits for the timeout period. I'm not thrilled with that solution but at least the user can adjust the timeout for situations where packet loss or delay are larger than the implementor expected. Regarding your second bullet, it does not really matter if the server can allow incoming requests or not. The TCP stack will happily accept several normal sized RTSP requests and queue them even if the network cable is unplugged. In the BSD socket API, acceptance for delivery does not imply anything about whether the data was actually delivered. One could argue that a non-BSD implementation could pass up the ACK so that the application knew the data had been received by the other side, but that only guarantees that the destination TCP stack has received the data. It still doesn't say whether the server application has received it. If the server is indeed in a state where it can accept requests but cannot process them for longer than the TCP is willing to wait (such that the TCP connection is broken) and it further cannot send 1xx responses to tell the client it's busy, I submit that the server needs to be redesigned. > Clients need some guidance about the expected response time of the > server to be able to detect these types of failures and deal with them > appropriately. At the least, it's more user-friendly to be able to say > "The server is not responding" than to simply wait for the user to give > up in frustration. >=20 > In practice, every client software author I've worked with has wanted to > know the maximum response time of the server. I think discussing the > issue in the specification and coming up with some guidelines is better > for interoperability than leaving it entirely up to each implementor. Again, I suggest playing with different network applications to see what implementors of other protocols have done. This issue is as old as TCP itself. I know it's tempting to try second guessing the network and pop up a dialog that says the server is not responding, please contact the provider, it's not our fault. But it's simply not possible to do this on top of TCP. The only feedback that you can give is positive. If the user gets tired of waiting, let the user press the "stop" button. It's not that hard. Really. There is also a difference between initial delay when establishing a TCP connection and the delay in RTSP request/response time. The usual delay that causes problems establishing the TCP connection is the DNS lookup.=20 When designing guidelines for clients, I think it's critical that we make this point. RTSP delay guidelines are in no way a guideline for the underlying TCP connection and they must _only_ be used after the TCP connection has been successfully established. --=20 To err is human; to really screw things up requires the root password. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/gdugqznSmcYu2m8RAiWGAJ47uOazeRCDaI9ENzZTIXDKSLb61wCfR+kO q8iR1KBSYYgsCL2L6gPQchI= =Bq1y -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 7 11:07:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05879 for ; Tue, 7 Oct 2003 11:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tQW-000616-Vf for mmusic-archive@odin.ietf.org; Tue, 07 Oct 2003 11:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97F74Z3023114 for mmusic-archive@odin.ietf.org; Tue, 7 Oct 2003 11:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tQW-00060j-K2 for mmusic-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 11:07: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 LAA05853 for ; Tue, 7 Oct 2003 11:06:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tQT-0006hB-00 for mmusic-web-archive@ietf.org; Tue, 07 Oct 2003 11:07:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6tQT-0006h7-00 for mmusic-web-archive@ietf.org; Tue, 07 Oct 2003 11:07:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tQU-0005zL-4l; Tue, 07 Oct 2003 11:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tQ6-0005un-KW for mmusic@optimus.ietf.org; Tue, 07 Oct 2003 11:06:38 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05769; Tue, 7 Oct 2003 11:06:27 -0400 (EDT) Message-Id: <200310071506.LAA05769@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, 07 Oct 2003 11:06:27 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-09.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP) Author(s) : J. Arkko, et. al. Filename : draft-ietf-mmusic-kmgmt-ext-09.txt Pages : 18 Date : 2003-10-7 This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-09.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-10-7111039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-7111039.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 7 17:13:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22739 for ; Tue, 7 Oct 2003 17:13:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6z8i-0008K2-RA for mmusic-archive@odin.ietf.org; Tue, 07 Oct 2003 17:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h97LD4ku031986 for mmusic-archive@odin.ietf.org; Tue, 7 Oct 2003 17:13:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6z8i-0008Jo-It for mmusic-web-archive@optimus.ietf.org; Tue, 07 Oct 2003 17:13: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 RAA22719 for ; Tue, 7 Oct 2003 17:12:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6z8g-0003v8-00 for mmusic-web-archive@ietf.org; Tue, 07 Oct 2003 17:13:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A6z8f-0003v4-00 for mmusic-web-archive@ietf.org; Tue, 07 Oct 2003 17:13:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6z8f-0008JN-Mi; Tue, 07 Oct 2003 17:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A6tRz-0006T2-25 for mmusic@optimus.ietf.org; Tue, 07 Oct 2003 11:08: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 LAA05968 for ; Tue, 7 Oct 2003 11:08:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A6tRw-0006ip-00 for mmusic@ietf.org; Tue, 07 Oct 2003 11:08:32 -0400 Received: from sea1-dav47.sea1.hotmail.com ([207.68.162.19] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1A6tRv-0006iG-00 for mmusic@ietf.org; Tue, 07 Oct 2003 11:08:32 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 7 Oct 2003 08:08:01 -0700 Received: from 132.210.72.178 by sea1-dav47.sea1.hotmail.com with DAV; Tue, 07 Oct 2003 15:07:59 +0000 X-Originating-IP: [132.210.72.178] X-Originating-Email: [joel_tran@hotmail.com] From: "Joel Tran" To: "Jonathan Rosenberg" , "Mmusic" Date: Tue, 7 Oct 2003 11:07:47 -0400 Message-ID: <002b01c38ce4$c4a92f40$b248d284@kamel> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 Oct 2003 15:08:01.0035 (UTC) FILETIME=[CCA5B5B0:01C38CE4] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Status of TURN Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jonathan, I would like to ask you two little questions concerning TURN. First, I would like to know what is the exact status of TURN? Will it be adopted as a Workgroup item of MMUSIC since TURN is refeered in various documents? Second, I would like to ask you if there is a reason why the lastest = version of the draft is not on the IETF web and only available throught http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? Thanks, ...J _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 9 12:10:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26054 for ; Thu, 9 Oct 2003 12:10:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dMb-0005GD-9R for mmusic-archive@odin.ietf.org; Thu, 09 Oct 2003 12:10:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99GA5bp020215 for mmusic-archive@odin.ietf.org; Thu, 9 Oct 2003 12:10:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dMb-0005Fy-4T for mmusic-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 12:10: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 MAA26050 for ; Thu, 9 Oct 2003 12:09:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dMZ-0000PA-00 for mmusic-web-archive@ietf.org; Thu, 09 Oct 2003 12:10:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7dMZ-0000P6-00 for mmusic-web-archive@ietf.org; Thu, 09 Oct 2003 12:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dMY-0005FV-L4; Thu, 09 Oct 2003 12:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7dLk-0005EJ-Dn for mmusic@optimus.ietf.org; Thu, 09 Oct 2003 12:09: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 MAA26024 for ; Thu, 9 Oct 2003 12:09:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7dLj-0000OP-00 for mmusic@ietf.org; Thu, 09 Oct 2003 12:09:11 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx with esmtp (Exim 4.12) id 1A7dLi-0000O2-00 for mmusic@ietf.org; Thu, 09 Oct 2003 12:09:10 -0400 Received: from chiimc01.npac.com (chiimc01.il.neustar.com [10.32.90.4]) by willow.neustar.com (8.11.6/8.11.6) with ESMTP id h99G8Ip27407; Thu, 9 Oct 2003 16:08:19 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id <4RGYJVW0>; Thu, 9 Oct 2003 11:08:58 -0500 Message-ID: From: "Peterson, Jon" To: "'Joel Tran'" , Jonathan Rosenberg , Mmusic Subject: RE: [MMUSIC] Status of TURN Date: Thu, 9 Oct 2003 11:08:58 -0500 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: , The Transport Area Directors understand that this document will proceed as an individual submission, outside the context of any of the working groups in the Transport Area. It is clearly of interest to a number of these working groups. I gather that at least one more revision needs to be undertaken before this document will be considered for publication as an RFC, but we're very interested to see it go forward. Jon Peterson NeuStar, Inc. (co-AD for Transport) > -----Original Message----- > From: Joel Tran [mailto:joel_tran@hotmail.com] > Sent: Tuesday, October 07, 2003 11:08 AM > To: Jonathan Rosenberg; Mmusic > Subject: [MMUSIC] Status of TURN > > > Hi Jonathan, > > I would like to ask you two little questions concerning TURN. > > First, I would like to know what is the exact status of TURN? > Will it be > adopted as a Workgroup item of MMUSIC since TURN is refeered > in various > documents? > > Second, I would like to ask you if there is a reason why the > lastest version > of the draft is not on the IETF web and only available throught > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > > Thanks, > ...J > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 9 12:53:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28966 for ; Thu, 9 Oct 2003 12:53:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e2d-0008Bs-Eh for mmusic-archive@odin.ietf.org; Thu, 09 Oct 2003 12:53:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99GrVS6031478 for mmusic-archive@odin.ietf.org; Thu, 9 Oct 2003 12:53:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e2d-0008Bd-B0 for mmusic-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 12:53:31 -0400 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28904 for ; Thu, 9 Oct 2003 12:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e28-00087T-Ov; Thu, 09 Oct 2003 12:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7e1d-00086m-22 for mmusic@optimus.ietf.org; Thu, 09 Oct 2003 12:52: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 MAA28839 for ; Thu, 9 Oct 2003 12:52:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7e1b-0001DS-00 for mmusic@ietf.org; Thu, 09 Oct 2003 12:52:27 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A7e1Z-0001Cq-00 for mmusic@ietf.org; Thu, 09 Oct 2003 12:52:26 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h99GiDUg028454; Thu, 9 Oct 2003 12:44:13 -0400 (EDT) Message-ID: <3F859055.2030600@dynamicsoft.com> Date: Thu, 09 Oct 2003 12:44:05 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peterson, Jon" CC: "'Joel Tran'" , Mmusic Subject: Re: [MMUSIC] Status of TURN References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks for the clarification, Jon. To answer Joel's second question - there were some mixups during the submission process last time, and the -02 never got into the archives. I've just resubmitted it so it should be there shortly. I am also hoping to get in a real revision (resulting in a -03 version) before the deadline. Please, if you have comments or questions, forward them to me. Thanks, Jonathan R. Peterson, Jon wrote: > The Transport Area Directors understand that this document will proceed as > an individual submission, outside the context of any of the working groups > in the Transport Area. It is clearly of interest to a number of these > working groups. > > I gather that at least one more revision needs to be undertaken before this > document will be considered for publication as an RFC, but we're very > interested to see it go forward. > > Jon Peterson > NeuStar, Inc. > (co-AD for Transport) > > >>-----Original Message----- >>From: Joel Tran [mailto:joel_tran@hotmail.com] >>Sent: Tuesday, October 07, 2003 11:08 AM >>To: Jonathan Rosenberg; Mmusic >>Subject: [MMUSIC] Status of TURN >> >> >>Hi Jonathan, >> >>I would like to ask you two little questions concerning TURN. >> >>First, I would like to know what is the exact status of TURN? >>Will it be >>adopted as a Workgroup item of MMUSIC since TURN is refeered >>in various >>documents? >> >>Second, I would like to ask you if there is a reason why the >>lastest version >>of the draft is not on the IETF web and only available throught >>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? >> >>Thanks, >>...J >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 10 01:24:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26428 for ; Fri, 10 Oct 2003 01:24:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pky-0003gh-QN for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 01:24:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9A5O4uT014150 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 01:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pky-0003fM-H6 for mmusic-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 01:24: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 BAA26396 for ; Fri, 10 Oct 2003 01:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pkv-0001tG-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 01:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7pku-0001tD-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 01:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pkw-0003er-3a; Fri, 10 Oct 2003 01:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7pkl-0003eA-AO for mmusic@optimus.ietf.org; Fri, 10 Oct 2003 01:23: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 BAA26381 for ; Fri, 10 Oct 2003 01:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7pki-0001st-00 for mmusic@ietf.org; Fri, 10 Oct 2003 01:23:48 -0400 Received: from mail.icst.pku.cn ([162.105.204.188] helo=mail.icst.pku.edu.cn) by ietf-mx with smtp (Exim 4.12) id 1A7pkh-0001sY-00 for mmusic@ietf.org; Fri, 10 Oct 2003 01:23:47 -0400 Received: (qmail 12871 invoked from network); 10 Oct 2003 05:26:52 -0000 Received: from unknown (HELO siduanfeng) (162.105.163.98) by mail.icst.pku.cn with SMTP; 10 Oct 2003 05:26:52 -0000 Message-ID: <01bc01c38eee$a0e811f0$f401a8c0@siduanfeng> From: "siduanfeng" To: Date: Fri, 10 Oct 2003 13:23:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 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 Content-Transfer-Encoding: base64 Subject: [MMUSIC] About set up the SIP server Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSB3YW50IHRvIHNldCB1cCBhIFNJUCBzZXJ2ZXIgaW4gbXkgbGFib3JhdG9yeSwgYW55b25lIGNv dWxkIHRlbGwgbWUgd2hhdCBjYW4gSSBkbz8gV2hlcmUgSSBjYW4gZmluZCB0aGUgc2VydmVyIHNv dXJjZSBjb2RlPyBXaGljaCBzeXN0ZW0gSSBzaG91bGQgdXNpbmcsIExpbnV4IG9yIFdpbmRvd3M/ DQpUaGFua3MuDQoNCnNpZHVhbmZlbmdAaWNzdC5wa3UuZWR1LmNu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 10 15:36:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15559 for ; Fri, 10 Oct 2003 15:36:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A833U-0005As-93 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 15:36:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9AJa4Do019886 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 15:36:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A833U-0005Af-3h for mmusic-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 15:36: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 PAA15534 for ; Fri, 10 Oct 2003 15:35:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A833S-0000VQ-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 15:36:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A833S-0000VM-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 15:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A833R-0005AD-Ox; Fri, 10 Oct 2003 15:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A832m-00059Z-Oq for mmusic@optimus.ietf.org; Fri, 10 Oct 2003 15:35: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 PAA15506 for ; Fri, 10 Oct 2003 15:35:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A832l-0000VJ-00 for mmusic@ietf.org; Fri, 10 Oct 2003 15:35:19 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1A832k-0000VG-00 for mmusic@ietf.org; Fri, 10 Oct 2003 15:35:18 -0400 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 10 Oct 2003 15:34:42 -0400 Message-ID: Thread-Topic: specifying the multicast interface Thread-Index: AcOPZDJAmE/cv7cXS0GVyeFvAKx5JA== From: "Matthew Heaney" To: X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] specifying the multicast interface Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable When creating a multicast session, it is possible to specify the outgoing interface using the IP_MULTICAST_IF socket option. Does RFC 2326 (or 3550/1889) prescribe a mechanism for specifying the interface? Analogously, the IP_ADD_MEMBERSHIP socket option allows the receiver to specify the multicast interface explicitly (via the imr_interface data member of the ip_mreq struct). Is there a mechanism (via the SDP DESCRIBE, I guess) for indicating the multicast interface? Thanks, Matt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 10 20:05:13 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01056 for ; Fri, 10 Oct 2003 20:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87FZ-00074q-Ls for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 20:04:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B04noH027193 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 20:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87FZ-00074R-EC for mmusic-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 20:04: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 UAA01028 for ; Fri, 10 Oct 2003 20:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87FX-00059z-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 20:04:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A87FW-00059t-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 20:04:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87En-0006x0-BT; Fri, 10 Oct 2003 20:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87E7-0006wW-Sm for mmusic@optimus.ietf.org; Fri, 10 Oct 2003 20:03: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 UAA00915; Fri, 10 Oct 2003 20:03:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87E5-000570-00; Fri, 10 Oct 2003 20:03:17 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1A87E4-00056n-00; Fri, 10 Oct 2003 20:03:16 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9B03GO01628; Fri, 10 Oct 2003 17:03:16 -0700 (PDT) Message-Id: <200310110003.h9B03GO01628@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: Fri, 10 Oct 2003 17:03:16 -0700 Subject: [MMUSIC] RFC 3605 on Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) 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 3605 Title: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) Author(s): C. Huitema Status: Standards Track Date: October 2003 Mailbox: huitema@microsoft.com Pages: 8 Characters: 17270 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-sdp4nat-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3605.txt The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. 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: <031010170132.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3605 --OtherAccess Content-Type: Message/External-body; name="rfc3605.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031010170132.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 10 20:51:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01054 for ; Fri, 10 Oct 2003 20:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87FZ-00074n-L8 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 20:04:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B04n8w027191 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 20:04:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87FZ-00074N-CZ for mmusic-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 20:04: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 UAA01026 for ; Fri, 10 Oct 2003 20:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87FX-00059x-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 20:04:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A87FW-00059s-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 20:04:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87En-0006x8-OW; Fri, 10 Oct 2003 20:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A87E9-0006wb-T9 for mmusic@optimus.ietf.org; Fri, 10 Oct 2003 20:03: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 UAA00923 for ; Fri, 10 Oct 2003 20:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A87E7-00057B-00 for mmusic@ietf.org; Fri, 10 Oct 2003 20:03:19 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 1A87E7-000577-00 for mmusic@ietf.org; Fri, 10 Oct 2003 20:03:19 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9B03JO01635; Fri, 10 Oct 2003 17:03:19 -0700 (PDT) Message-Id: <200310110003.h9B03JO01635@gamma.isi.edu> To: rfc-dist@rfc-editor.org 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: Fri, 10 Oct 2003 17:03:19 -0700 Subject: [MMUSIC] RFC 3605 on Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) 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 3605 Title: Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP) Author(s): C. Huitema Status: Standards Track Date: October 2003 Mailbox: huitema@microsoft.com Pages: 8 Characters: 17270 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mmusic-sdp4nat-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3605.txt The Session Description Protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these ports have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. 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: <031010170132.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3605 --OtherAccess Content-Type: Message/External-body; name="rfc3605.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <031010170132.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 10 21:07:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03346 for ; Fri, 10 Oct 2003 21:07:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A88Dv-0001og-5N for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 21:07:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B17ARl006966 for mmusic-archive@odin.ietf.org; Fri, 10 Oct 2003 21:07:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A88Du-0001o9-E5 for mmusic-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 21:07: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 VAA03314 for ; Fri, 10 Oct 2003 21:07:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A88Dr-0005ys-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 21:07:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A88Dr-0005yp-00 for mmusic-web-archive@ietf.org; Fri, 10 Oct 2003 21:07:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A88Dk-0001kl-Vf; Fri, 10 Oct 2003 21:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A88DF-0001iV-Np for mmusic@optimus.ietf.org; Fri, 10 Oct 2003 21:06:29 -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 VAA03276 for ; Fri, 10 Oct 2003 21:06:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A88DD-0005y8-00 for mmusic@ietf.org; Fri, 10 Oct 2003 21:06:27 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1A88DC-0005wZ-00 for mmusic@ietf.org; Fri, 10 Oct 2003 21:06:26 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9B15qPa046404 for ; Fri, 10 Oct 2003 18:05:52 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Oct 2003 18:05:51 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17B62@misty.packetvideo.com> From: Thomas Zeng To: mmusic@ietf.org Date: Fri, 10 Oct 2003 18:05:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C38F93.D00A5B50" Subject: [MMUSIC] strawman draft for signalling end of stream 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C38F93.D00A5B50 Content-Type: text/plain; charset="iso-8859-1" Hi: During Vienna IETF, I took the action to write this draft, which will be an extension of the core RTSP protocol. It's been 2 month, I finally have the first version, which is attached. Thanks in advance for your comments, thomas <> ------_=_NextPart_000_01C38F93.D00A5B50 Content-Type: text/plain; name="rtsp_end_of_stream.txt" Content-Disposition: attachment; filename="rtsp_end_of_stream.txt" Content-Transfer-Encoding: quoted-printable =0A= MMUSIC Thomas M. = Zeng=0A= P. Greg = Sherwood=0A= Internet-Draft = PacketVideo=0A= Expires: April 29, 2004 Sept 29, = 2003=0A= =0A= =0A= Signalling End Of Stream in RTSP=0A= draft-zeng-mmusic-00=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that = other=0A= groups may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at http://=0A= www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on Apr. 29, 2004.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document describes a new RTSP method called END_OF_STREAM, = which =0A= extends the core RTSP protocol to enable one RTSP protocol entity to = =0A= signal other entity(s) =0A= that it has no more media data to send. This request could be issued = either with a =0A= non-aggregate or aggregate control URI, the latter implies that all = media streams =0A= in the aggregate session have run out of media data.=0A= =0A= The receiver of this RTSP request is expected to reply with 200 OK = response.=0A= =0A= Since END_OF_STREAM represents an extension to the core RTSP = protocol, a feature tag,=0A= "method.eos", is defined to facilitate capability negotiation using = RTSP extension =0A= mechanism [RTSP_NEW].=0A= =0A= =0A= 1. Motivation=0A= =0A= In the core RTSP protocol [RTSP_NEW], an RTSP client relies on = the=0A= media transport mechanism to signal end of stream.=0A= =0A= When the media transport mechanism happens to be RTP over UDP, this = =0A= is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are = =0A= some drawbacks with this approach:=0A= =0A= 1. When the server sends an RTCP BYE packet with its SSRC, the = server=0A= is giving up=0A= the SSRC (see section 8.2 in [RTP_NEW]). The server would be = required to =0A= switch to a new SSRC on a subsequent PLAY of the same media = stream.=0A= Since server's SSRC is only communicated in the Transport = header of SETUP =0A= response, the server would not have an opportunity to send a = new value to =0A= the player, and the client would have to discover the SSRC from = the=0A= incoming RTP packets. =0A= =0A= 2. RTCP BYE packet method does not offer a simple, gurranteed = method of delievering=0A= an end-of-stream announcement.=0A= =0A= 3. RTCP BYE packet method does not offer the option to have a = single aggregate=0A= end-of-stream announcemnt for all media streams in the RTSP = session.=0A= =0A= 4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot = send =0A= RTCP BYE =0A= before leaving the RTP session if it has not already sent at = least one =0A= RTP or RTCP packet. This is a problem under error conditions. = Consider the case =0A= where an RTP session has just started (i.e., RTSP PLAY has been = =0A= successfully=0A= acknowledged with an RTSP 200 OK response), and the sender = attempts to =0A= retrieve media frames from its media source. The media source = fails =0A= to provide any media frame due to its internal error such as = =0A= file corruption. The sender should inform its receiver(s) but = it cannot=0A= send BYE packets.=0A= =0A= =0A= The motivation to solve the above issues is particularly high for = =0A= unicast streaming applications that use RTSP over TCP in the control = plane,=0A= and RTP over UDP in the media transport. =0A= =0A= There is also the desire to have an EOS (End Of Stream) =0A= signalling mechanism =0A= for non-RTP delivery. One such delivery is MPEG2 transport streams = used in =0A= the cable TV environment. In non-IP delivery environments, the = transport =0A= typically remains allocated even if no media is being delivered. = This=0A= means that a client cannot watch for the server to close the=0A= transport to signal the end of stream. Meanwhile, watching for the = =0A= incoming media to stop is unreliable. Short=0A= timeouts can trigger a false end of media detection if the=0A= media flow is temporarily delayed. Long timeouts introduce=0A= unacceptable latencies. Clients are unable to distinguish=0A= between a normal end of stream and an error condition that=0A= resulted in the media delivery stopping.=0A= =0A= We note that using TEARDOWN from server to client is not appropriate = =0A= because:=0A= 1. TEARDOWN is currently not allowed from server to client = [RTSP_NEW];=0A= 2. Even if TEARDOWN is made available in server to client = direction, =0A= the definition of TEARDOWN requires that, if the request URI is = =0A= aggregate, that the session must be de-allocated by the server. = =0A= There are RTSP applications that use SET_PARAMETER from client = to=0A= server as the means to report session QoS statistics, but if=0A= server uses TEARDOWN on aggregate URL to signal end of stream, = =0A= the client can no longer use SET_PARAMETER with a session = header. =0A= 3. In general, RTSP, being a client-server protocol,=0A= should let client, not server to control session state. But = TEARDOWN=0A= on aggregate URL will change session from PLAYING state to INIT = state.=0A= =0A= We note that using PAUSE from server to client is not appropriate = either,=0A= because PAUSE will change the state of the RTSP session.=0A= =0A= We note also that using ANNOUNCE from server to client is not = suitable, for two reasons:=0A= 1. ANNOUNCE from server to client is used in RFC2326 to update = session description. =0A= Extending it to indicate end-of-stream event is awkward.=0A= 2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].=0A= =0A= The next section describes our solution.=0A= =0A= 3. Solution Using END_OF_STREAM method=0A= =0A= We introduce a new RTSP method to signal end of stream in = applications=0A= where an persistent RTSP connection is maintained between server and = client.=0A= The new method is an RTSP "extension-method" [RTSP_NEW]. It is = called=0A= END_OF_STREAM, and is a request from media sender=0A= to receiver. In the case of RTSP client playing media streams sent = by RTSP server,=0A= the END_OF_STREAM is sent from server to client. In the use case = where RTSP server is=0A= recording media sent by RTSP client, the END_OF_STREAM requet could = be sent from an=0A= RTSP client to server. =0A= =0A= As any other RTSP request method, END_OF_STREAM must be acknowledged = with a response.=0A= =0A= 3.1 The Definition of END_OF_STREAM=0A= =0A= The END_OF_STREAM request for a URI signals the fact that no more = RTP packets will be=0A= sent. Here is an example:=0A= =0A= S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0=0A= CSeq: 10=0A= Session: 12345678=0A= Range: npt=3D0-200=0A= RTP-Info: = url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102,=0A= url=3Drtsp://foo.com/bar.avi/streamid=3D1;seq=3D30211 = =0A= Reason: End of range reached=0A= =0A= C->S: RTSP/1.0 200 OK =0A= CSeq: 10=0A= Session: 12345678=0A= =0A= An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" = headers.=0A= It SHOULD include "RTP-Info" header.=0A= The RTP-Info in server's END_OF_STREAM request=0A= is used to indicate the sequence number of =0A= the ending RTP packet for each media stream.=0A= =0A= An END_OF_STREAM requet MAY include a new "Reason" header, defined = as a =0A= string, whose purpose is to allow the server to explain why stream = has ended,=0A= and whose ABNF definition is given below:=0A= =0A= Reason =3D "Reason" ":" Reason-Phrase CRLF=0A= =0A= where:=0A= -- "Reason-Phrase" is a parameter defined in section 7.1.1 of = [RTSP_NEW].=0A= =0A= =0A= Note that the server is free to use any text as "Reason-Phrase". In = certain=0A= applications, the client=0A= may display the text, in its entirety, to end user to improve = user=0A= friendliness.=0A= =0A= END_OF_STREAM does not remove session ID, nor does it change the = state=0A= of the RTSP session.=0A= =0A= END_OF_STREAM may be applied to either aggregate or non-aggregate = URI.=0A= =0A= END_OF_STREAM does not apply if the RTSP session is not in = PLAYING=0A= state. If a client receives END_OF_STREAM while it is not in PLAYING = =0A= state, it must reply with a 455 response: Method Not Valid in This = State.=0A= =0A= We note that client can piggy back QoS statistics as a entity body = in=0A= its 200 OK response to the END_OF_STREAM request from the server. = =0A= =0A= 3.2 Limitations=0A= =0A= END_OF_STREAM method is applicable only if the server has the = means=0A= to contact the client when it reaches the end of a media stream.=0A= This may not be possible if the RTSP connection between server = and=0A= client is not persistent. When it is time to send END_OF_STREAM = but=0A= the server does not have connection to the client, the server = will=0A= simply skip END_OF_STREAM. That is to say, the server will not =0A= queue up the END_OF_STREAM message.=0A= =0A= =0A= 4. Feature tag=0A= =0A= The END_OF_STREAM feature is represented by a feature tag (see = [RTSP_NEW]=0A= for how to use feature tags in capability negotiations).=0A= =0A= The feature tag is:=0A= =0A= method.eos=0A= =0A= which means that the END_OF_STREAM method is fully supported. By = fully=0A= we mean either at non-aggregate or aggregate level.=0A= =0A= 5. Use Case=0A= =0A= In this example, the server sends END_OF_STREAM request to client = for=0A= one live media stream, because upstream source terminates the = stream=0A= after 200 seconds. The fact that the stream has played for 200 = seconds=0A= is communicated by the Range header in the END_OF_STREAM request.=0A= =0A= C->S: PLAY rtsp://foo.com/bar.avi/streamid=3D0 RTSP/1.0=0A= Supported: method.eos=0A= CSeq: 10=0A= Session: 12345678=0A= Range: 0-200=0A= =0A= S->C: RTSP/1.0 200 OK=0A= Supported: method.eos=0A= CSeq: 10=0A= Session: 12345678=0A= RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D0; = rtptime=3D0 =0A= =0A= S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=3D0 = RTSP/1.0=0A= CSeq: 123=0A= Session: 12345678=0A= Range: npt=3D0-200; bytes=3D0-200000=0A= RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102 = =0A= Reason: End of range reached=0A= =0A= C->S: RTSP/1.0 200 OK =0A= CSeq: 123=0A= Session: 12345678=0A= =0A= In the END_OF_STREAM request, the client will learn that the server = has =0A= completed the stream as requested (as indicated by the "End of range = reached" Reason).=0A= =0A= From the two RTP-Info headers, one in PLAY response, one in = END_OF_STREAM requst,=0A= the client can derive the total number=0A= of RTP packets that the server has sent. From the npt field in the = Range header, =0A= the client knows the presentation time that this stream has covered, = from the=0A= server's point of view, while the byte-range field can optional = inform the =0A= client how much media data, in bytes, that the server has sent. =0A= =0A= 5. Security Considerations=0A= =0A= Because there is only one new TEXT header, "Reason", added by our = =0A= new RTSP method,=0A= the security considerations outlined in [RTSP_NEW] apply here as = well.=0A= =0A= 6. IANA Considerations=0A= =0A= A new method name, and its associated feature tag need to be = registered =0A= with IANA.=0A= =0A= -- Method name: END_OF_STREAM=0A= =0A= -- feature tag: method.eos=0A= =0A= =0A= =0C=0A= =0A= Normative References=0A= =0A= [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., = =0A= "Real Time Streaming Protocol", =0A= draft-ietf-mmusic-rfc2326bis-04.txt=0A= =0A= [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assignees.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= =0A= =0A= =0A= =0A= =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Acknowledgement=0A= =0A= Thanks to Sean Sheedy for suggesting the inclusion of "Range" = header.=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= ------_=_NextPart_000_01C38F93.D00A5B50-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Oct 11 20:01:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17900 for ; Sat, 11 Oct 2003 20:01:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Tff-0002nC-CO for mmusic-archive@odin.ietf.org; Sat, 11 Oct 2003 20:01:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9C01F4e010733 for mmusic-archive@odin.ietf.org; Sat, 11 Oct 2003 20:01:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8Tff-0002n2-5u for mmusic-web-archive@optimus.ietf.org; Sat, 11 Oct 2003 20:01: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 UAA17886 for ; Sat, 11 Oct 2003 20:01:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8Tfd-0001Fo-00 for mmusic-web-archive@ietf.org; Sat, 11 Oct 2003 20:01:13 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8Tfc-0001Fk-00 for mmusic-web-archive@ietf.org; Sat, 11 Oct 2003 20:01:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8TfR-0002i9-PB; Sat, 11 Oct 2003 20:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8TfP-0002hQ-JX for mmusic@optimus.ietf.org; Sat, 11 Oct 2003 20:00: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 UAA17858 for ; Sat, 11 Oct 2003 20:00:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8TfN-0001FQ-00 for mmusic@ietf.org; Sat, 11 Oct 2003 20:00:57 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1A8TfM-0001FN-00 for mmusic@ietf.org; Sat, 11 Oct 2003 20:00:56 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sat, 11 Oct 2003 17:00:42 -0700 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by flawless.real.com with esmtp; Wed, 01 Oct 2003 20:29:09 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1A4uA0-0002dp-00 for ; Wed, 01 Oct 2003 20:29:48 -0700 Date: Wed, 01 Oct 2003 20:28:33 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on flawless.real.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #100 - 8 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net) 2. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative (SourceForge.net) 3. [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification (SourceForge.net) 4. [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification (SourceForge.net) 5. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net) 6. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative (SourceForge.net) 7. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup (SourceForge.net) 8. [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:16:50 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 Bugs item #533691, was opened at 2002-03-22 12:36 Message generated for change (Comment added) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 Category: None >Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) >Assigned to: Aravind Narasimhan (arvy_n) Summary: Clarify Range Where t0 <= t1 Initial Comment: If the server receives a PLAY range from t0-t1, where t0 < t1, should it reject the PLAY, or should the server play backwards as if the timescale is -1? If t0 = t1, should the server send any media data after responding 200 OK? We've seen different servers behave differently in this scenario. ---------------------------------------------------------------------- >Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:16 Message: Logged In: YES user_id=437699 The following text has been added to the spec with regards to this bug: By default, range intervals increase, where the second point is larger than the first point. Example: Range: npt=10-15 However, range intervals can also decrease if the Scale header (see section 13.34) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired. Example: Scale: -1 Range: npt=15-10 Decreasing ranges are still half open intervals as described above. Thus, For range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback. Example: Scale: -1 Range: npt=15-0 In this range both 15 and 0 are closed. A decreasing range interval without a corresponding negative Scale header is not valid. ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2003-03-05 12:53 Message: Logged In: YES user_id=20397 If scale positive, t1 must >= t0. Otherwise, t1 must <= t0 ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2002-03-22 12:41 Message: Logged In: YES user_id=20397 I just came across 513880, which is closely related. That is to say, if timescale is positive, should the play range to be required to have t1 > t0? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:22:04 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative Bugs item #513880, was opened at 2002-02-06 13:48 Message generated for change (Comment added) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 Category: None >Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) >Assigned to: Aravind Narasimhan (arvy_n) Summary: How to use Range when Scale is negative Initial Comment: I think the spec could use an example that shows how to use the Range header when rewinding (Scale header is set to a negative value.) Or, instead of an example, some explanatory text could be added. The issue that I find a little bit confusing is how the server should specify the end of the range. The end of the range would be numerically smaller than the start of the range. I think the following illustrates a valid exchange: C->S: PLAY rtsp://server/a RTSP/1.0 Scale: -1 Range: npt=45- S->C: RTSP/1.0 200 OK Scale: -1 Range: npt=45-0 This is the type of example that I think would be nice to have in the spec. ---------------------------------------------------------------------- >Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:22 Message: Logged In: YES user_id=437699 The following text has been added to the spec with regards to this bug: When indicating a negative scale for a reverse playback, the Range header must indicate a decreasing range as described in section 13.29. Example of playing in reverse at 3.5 times normal rate: Scale: -3.5 Range: npt=15-10 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 12:29 Message: Logged In: YES user_id=302620 This needs to be discussed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:36:09 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification Bugs item #663715, was opened at 2003-01-07 09:31 Message generated for change (Comment added) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 Category: None Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Aravind Narasimhan (arvy_n) Summary: Requirement levels for Transport:SSRC needs clarification Initial Comment: The SSRC parameter in the transport header has a few unclarities. - Why should a client be allowed to propose a SSRC to the server? - If allowed as current text indicates, what is the requirement level on the server to follow the proposed value. MAY or SHOULD. First I would like to know the motivation a client has to suggest a SSRC. This can probably not be removed but unless there is good reasons for it I think the requirement on a server to follow the request is MAY. With a good motivation the level is SHOULD. ---------------------------------------------------------------------- >Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:36 Message: Logged In: YES user_id=437699 To address this bug the following text has been added to 13.40 of bis04: ssrc: The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [23] value that will be used by the media server for RTP packets within the stream. It is expressed as an eight digit hexadecimal value. If the server does not act as a synchronization source for stream data (for instance, server is a translator, reflector, etc.) the value will be the "packet sender's SSRC" that would have been used in the RTCP Receiver Reports generated by the server, regardless of whether the server actually generates RTCP RRs. If there are multiple sources within the stream, the ssrc parameter only indicates the value for a single synchronization source. Other sources must be deduced from the actual RTP/RTCP stream. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP in RFC 1889. If the parameter is included in the transport header of a SETUP request, the server MAY ignore it, and choose an appropriate SSRC for the stream. It MAY set the ssrc parameter in the transport header of the response. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-12 07:31 Message: Logged In: YES user_id=302620 Plan is to deprecate the behavior that a client is allowed to specify SSRC to the server. See telecon minutes from 28 April 2003. the behavior on how it shall be used will also be clarified. See discussion on multiple SSRCs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:38:13 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-663715 ] Requirement levels for Transport:SSRC needs clarification Bugs item #663715, was opened at 2003-01-07 09:31 Message generated for change (Settings changed) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Aravind Narasimhan (arvy_n) Summary: Requirement levels for Transport:SSRC needs clarification Initial Comment: The SSRC parameter in the transport header has a few unclarities. - Why should a client be allowed to propose a SSRC to the server? - If allowed as current text indicates, what is the requirement level on the server to follow the proposed value. MAY or SHOULD. First I would like to know the motivation a client has to suggest a SSRC. This can probably not be removed but unless there is good reasons for it I think the requirement on a server to follow the request is MAY. With a good motivation the level is SHOULD. ---------------------------------------------------------------------- Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:36 Message: Logged In: YES user_id=437699 To address this bug the following text has been added to 13.40 of bis04: ssrc: The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [23] value that will be used by the media server for RTP packets within the stream. It is expressed as an eight digit hexadecimal value. If the server does not act as a synchronization source for stream data (for instance, server is a translator, reflector, etc.) the value will be the "packet sender's SSRC" that would have been used in the RTCP Receiver Reports generated by the server, regardless of whether the server actually generates RTCP RRs. If there are multiple sources within the stream, the ssrc parameter only indicates the value for a single synchronization source. Other sources must be deduced from the actual RTP/RTCP stream. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP in RFC 1889. If the parameter is included in the transport header of a SETUP request, the server MAY ignore it, and choose an appropriate SSRC for the stream. It MAY set the ssrc parameter in the transport header of the response. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-12 07:31 Message: Logged In: YES user_id=302620 Plan is to deprecate the behavior that a client is allowed to specify SSRC to the server. See telecon minutes from 28 April 2003. the behavior on how it shall be used will also be clarified. See discussion on multiple SSRCs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=663715&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:38:17 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 Bugs item #533691, was opened at 2002-03-22 12:36 Message generated for change (Settings changed) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Aravind Narasimhan (arvy_n) Summary: Clarify Range Where t0 <= t1 Initial Comment: If the server receives a PLAY range from t0-t1, where t0 < t1, should it reject the PLAY, or should the server play backwards as if the timescale is -1? If t0 = t1, should the server send any media data after responding 200 OK? We've seen different servers behave differently in this scenario. ---------------------------------------------------------------------- Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:16 Message: Logged In: YES user_id=437699 The following text has been added to the spec with regards to this bug: By default, range intervals increase, where the second point is larger than the first point. Example: Range: npt=10-15 However, range intervals can also decrease if the Scale header (see section 13.34) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired. Example: Scale: -1 Range: npt=15-10 Decreasing ranges are still half open intervals as described above. Thus, For range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback. Example: Scale: -1 Range: npt=15-0 In this range both 15 and 0 are closed. A decreasing range interval without a corresponding negative Scale header is not valid. ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2003-03-05 12:53 Message: Logged In: YES user_id=20397 If scale positive, t1 must >= t0. Otherwise, t1 must <= t0 ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2002-03-22 12:41 Message: Logged In: YES user_id=20397 I just came across 513880, which is closely related. That is to say, if timescale is positive, should the play range to be required to have t1 > t0? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:38:59 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative Bugs item #513880, was opened at 2002-02-06 13:48 Message generated for change (Settings changed) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Aravind Narasimhan (arvy_n) Summary: How to use Range when Scale is negative Initial Comment: I think the spec could use an example that shows how to use the Range header when rewinding (Scale header is set to a negative value.) Or, instead of an example, some explanatory text could be added. The issue that I find a little bit confusing is how the server should specify the end of the range. The end of the range would be numerically smaller than the start of the range. I think the following illustrates a valid exchange: C->S: PLAY rtsp://server/a RTSP/1.0 Scale: -1 Range: npt=45- S->C: RTSP/1.0 200 OK Scale: -1 Range: npt=45-0 This is the type of example that I think would be nice to have in the spec. ---------------------------------------------------------------------- Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 11:22 Message: Logged In: YES user_id=437699 The following text has been added to the spec with regards to this bug: When indicating a negative scale for a reverse playback, the Range header must indicate a decreasing range as described in section 13.29. Example of playing in reverse at 3.5 times normal rate: Scale: -3.5 Range: npt=15-10 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 12:29 Message: Logged In: YES user_id=302620 This needs to be discussed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 08:50:12 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup Bugs item #513737, was opened at 2002-02-06 08:26 Message generated for change (Settings changed) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open Resolution: Fixed Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Aravind Narasimhan (arvy_n) Summary: Unclarities when doing resetup Initial Comment: Setup is used to change transport parameters of a already setuped stream. What happends if the new SETUP contains errors? Except of responding with an error message, what happends to the session and transport state? It should be clarified in the specification. Which of the following alternatives are correct? 1. Keep the old setting and states as if the second SETUP never happend. 2. Invalidate the media in the session until a correct setup has happend. To me case 1 seems more natural but will require more from the server. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-15 04:09 Message: Logged In: YES user_id=302620 A clarified third paragraph in the SETUP section (11.3) has been added. If a setup request fails the previous state shall be left as it was, i.e. proposal 1 in the initial declartion of this bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 01 Oct 2003 09:00:15 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-630920 ] RTP-Info does not support multiple SSRC Bugs item #630920, was opened at 2002-10-30 02:44 Message generated for change (Comment added) made by arvy_n You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP-Info does not support multiple SSRC Initial Comment: The RTP-Info header can't be used to synchronize multiple RTP flows using different SSRC as a single media stream. As each SSRC has its own RTP sequence and timestamp space to allow synchronization it needs to be possible to give these values for each SSRC in the media stream. This bug has connection with bug# 625352. ---------------------------------------------------------------------- >Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 12:00 Message: Logged In: YES user_id=437699 The following text has been added to 13.33 of bis04 to address this bug: The RTP-Info response-header field is used to set RTP-specific parameters in the PLAY response. These parameters correspond to the synchronization source identified by the ssrc parameter of the Transport response header in the SETUP reponse. For streams using RTP as transport protocol the RTP-Info header SHALL be part of a 200 response to PLAY. . . . Additionally, the RTP-Info header parameter fields only apply to a single SSRC within a stream (the SSRC reported in the transport response header; see section 13.40). If there are multiple synchronization sources present within a RTP session, RTCP must be used to map RTP and NTP timestamps for those sources, for both synchronization and drift-checking. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=630920&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Oct 12 19:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02864 for ; Sun, 12 Oct 2003 19:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8pDy-0008R8-82 for mmusic-archive@odin.ietf.org; Sun, 12 Oct 2003 19:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9CN26SO032426 for mmusic-archive@odin.ietf.org; Sun, 12 Oct 2003 19:02:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8pDy-0008Qv-0s for mmusic-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 19:02: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 TAA02853 for ; Sun, 12 Oct 2003 19:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8pDu-0003tM-00 for mmusic-web-archive@ietf.org; Sun, 12 Oct 2003 19:02:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8pDu-0003tJ-00 for mmusic-web-archive@ietf.org; Sun, 12 Oct 2003 19:02:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8pDt-0008QN-UG; Sun, 12 Oct 2003 19:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8pDF-0008PA-DK for mmusic@optimus.ietf.org; Sun, 12 Oct 2003 19:01: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 TAA02844 for ; Sun, 12 Oct 2003 19:01:09 -0400 (EDT) From: Nicolas.Ramponi@ses-astra.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8pDB-0003tB-00 for mmusic@ietf.org; Sun, 12 Oct 2003 19:01:17 -0400 Received: from clyde.ses-astra.com ([194.154.219.60]) by ietf-mx with esmtp (Exim 4.12) id 1A8pD5-0003sz-00 for mmusic@ietf.org; Sun, 12 Oct 2003 19:01:11 -0400 Received: from srv01.gen.btz.aia.lu (srv01.gen.btz.aia.lu [193.168.96.22]) by clyde.ses-astra.com (8.12.10/8.12.9) with ESMTP id h9CN0YiT028319 for ; Mon, 13 Oct 2003 01:00:36 +0200 (CEST) To: mmusic@ietf.org Message-ID: Date: Mon, 13 Oct 2003 01:00:34 +0200 X-MIMETrack: Serialize by Router on SRV01/BTZ(Release 5.0.12 |February 13, 2003) at 13/10/2003 01:00:36 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Nicolas Ramponi/BTZ is out of the office. 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 will be out of the office starting 10/11/2003 and will not return until 10/25/2003. I will respond to your message when I return. In case of urgent matters, you can contact Thierry Draus -- DISCLAIMER: This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, or rely on this e-mail. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 13 13:51:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17277 for ; Mon, 13 Oct 2003 13:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qV-0006jL-K7 for mmusic-archive@odin.ietf.org; Mon, 13 Oct 2003 13:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9DHp3Ko025865 for mmusic-archive@odin.ietf.org; Mon, 13 Oct 2003 13:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qV-0006j6-E1 for mmusic-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 13:51:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17246 for ; Mon, 13 Oct 2003 13:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96qT-00064i-00 for mmusic-web-archive@ietf.org; Mon, 13 Oct 2003 13:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A96qS-00064e-00 for mmusic-web-archive@ietf.org; Mon, 13 Oct 2003 13:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96qT-0006i0-Q8; Mon, 13 Oct 2003 13:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A96px-0006fR-4a for mmusic@optimus.ietf.org; Mon, 13 Oct 2003 13:50:29 -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 NAA17203 for ; Mon, 13 Oct 2003 13:50:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A96pu-00064C-00 for mmusic@ietf.org; Mon, 13 Oct 2003 13:50:26 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1A96pt-00063Y-00 for mmusic@ietf.org; Mon, 13 Oct 2003 13:50:26 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9DHnkPa024082; Mon, 13 Oct 2003 10:49:46 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Oct 2003 10:49:45 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17B66@misty.packetvideo.com> From: Thomas Zeng To: "'Matthew Heaney'" , mmusic@ietf.org Subject: RE: [MMUSIC] specifying the multicast interface Date: Mon, 13 Oct 2003 10:49:41 -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: , Dear Matthew: Yes, you can provide the IP of the selected IF via the c= line in SDP, but the final say is upto RTSP negotiations, ie., you can use the Transport header in the SETUP request/response to over-ride SDP. Transport header has the following general parameters, quoting 2326: unicast | multicast: mutually exclusive indication of whether unicast or multicast delivery will be attempted. Default value is multicast. Clients that are capable of handling both unicast and multicast transmission MUST indicate such capability by including two full transport-specs with separate parameters for each. destination: The address to which a stream will be sent. The client may specify the multicast address with the destination parameter. To avoid becoming the unwitting perpetrator of a remote- controlled denial-of-service attack, a server SHOULD authenticate the client and SHOULD log such attempts before allowing the client to direct a media stream to an address not chosen by the server. This is particularly important if RTSP commands are issued via UDP, but implementations cannot rely on TCP as reliable means of client identification by itself. A server SHOULD not allow a client to direct media streams to an address that differs from the address commands are coming from. source: If the source address for the stream is different than can be derived from the RTSP endpoint address (the server in playback or the client in recording), the source MAY be specified. This information may also be available through SDP. However, since this is more a feature of transport than media initialization, the authoritative source for this information should be in the SETUP response. Hope this is the answer you are looking for. - thomas -----Original Message----- From: Matthew Heaney [mailto:mheaney@on2.com] Sent: Friday, October 10, 2003 12:35 PM To: mmusic@ietf.org Subject: [MMUSIC] specifying the multicast interface When creating a multicast session, it is possible to specify the outgoing interface using the IP_MULTICAST_IF socket option. Does RFC 2326 (or 3550/1889) prescribe a mechanism for specifying the interface? Analogously, the IP_ADD_MEMBERSHIP socket option allows the receiver to specify the multicast interface explicitly (via the imr_interface data member of the ip_mreq struct). Is there a mechanism (via the SDP DESCRIBE, I guess) for indicating the multicast interface? Thanks, Matt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 13 23:28:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11562 for ; Mon, 13 Oct 2003 23:28:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fqw-0000O2-0I for mmusic-archive@odin.ietf.org; Mon, 13 Oct 2003 23:28:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E3S5r8001485 for mmusic-archive@odin.ietf.org; Mon, 13 Oct 2003 23:28:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fqv-0000Ns-Rf for mmusic-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 23: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 XAA11556 for ; Mon, 13 Oct 2003 23:27:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Fqt-0005Dj-00 for mmusic-web-archive@ietf.org; Mon, 13 Oct 2003 23:28:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Fqt-0005Dg-00 for mmusic-web-archive@ietf.org; Mon, 13 Oct 2003 23:28:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fqr-0000NE-84; Mon, 13 Oct 2003 23:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Fqg-0000Mz-4F for mmusic@optimus.ietf.org; Mon, 13 Oct 2003 23:27: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 XAA11539 for ; Mon, 13 Oct 2003 23:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Fqd-0005DE-00 for mmusic@ietf.org; Mon, 13 Oct 2003 23:27:48 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1A9Fqd-0005D2-00 for mmusic@ietf.org; Mon, 13 Oct 2003 23:27:47 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Mon, 13 Oct 2003 20:27:28 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Mon, 13 Oct 2003 20:27:28 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Mon, 13 Oct 2003 20:25:18 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1A9Foq-0001fU-00 for ; Mon, 13 Oct 2003 20:25:56 -0700 Date: Mon, 13 Oct 2003 20:24:48 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on goodfellas.real.com X-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DEAR_SOMETHING, NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #101 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. PARTNERSHIP. (DENIS DUBE) --__--__-- Message: 1 From: DENIS DUBE To: rtspspec-bugs@lists.sourceforge.net Reply-To: dubedube88@netscape.net Date: Mon, 13 Oct 2003 22:30:22 +0200 Subject: [rtspspec-bugs] PARTNERSHIP. This is a multi-part message in MIME format --9854268a-fdc0-11d7-9787-444553540000 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable FROM: DENIS DUBE E-mail:dubedube88@netscape.net TEL:+31-630-550-312 AMSTERDAM Dear Sir, FUNDS FOR INVESTMENT I deem it necessary to first introduce myself before putting this proposal to you for consideration. I am Dr.Denis Dube a principal official managing, accounting, securing and = payment of Sierra Leone contractors. I however. was moved to write you this letter for a joint venture for = profitable investment of a medium term capital worth TWENTY MILLION UNITED = STATES DOLLARS ($20 MILLION)which we have within our authority for immediate = investment. It is vital to inform you that this fund in question does not fall within the = category of laundered or drug related money, but rather my colleagues and I = are principal officials responsible for managing, accounting,securing of = funds for various projects in Sierra Leone.We have been able to temporarily = set aside this amount which makes up only a little fraction of the funds = schedule for use in the year 2009 in the last phase of the six years = nationwide project of reconstruction and intallation of infrastructural = facilities worth Nine Hundred and Twenty Five Million dollars ($925million) = allocated for these projects. The two major contracting firms TRADE PARTNERS UK AND TGS-NOPEC have been = paid motivational amount and operations have commence while major balance = payments are schedule for the last quaters of 2009 when the last phase of the = projects would be completed. Therefore, considering the fact that these funds = wounld be lying idle for six yars, we decided to take out ($20million)and we = are required to return this amount within six years back to the treasury when = we are expected to present our audit report. We hereby ask you to use your vast expertise in sourcing and negotiating for = the project that you consider most lucrative, As a matter of fact we have = successfully moved this funds to a security and finance company in Amsterdam, = The Netherlands for safe custody and I am currently in Amsterdam for the = purpose of securing a would be investor/partner. In the mean time, could you = indicate your willingness to be part of this proposal by acknowledging this = mail via e-mail or telephone number +31-630-550-312 so that we can discuss = contructivelly all relevant details and evaluation of your proposed = investment. I await your immidiate response. Kind regards, Denis Dube(Dr) --9854268a-fdc0-11d7-9787-444553540000-- End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 03:28:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28757 for ; Tue, 14 Oct 2003 03:28:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JbF-0003YR-7z for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:28:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7S9Of013664 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JbE-0003YJ-JZ for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:28: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 DAA28754 for ; Tue, 14 Oct 2003 03:27:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9JbC-0006rk-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:28:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9JbB-0006rh-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:28:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jb8-0003Xr-3e; Tue, 14 Oct 2003 03:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jal-0003XW-H4 for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 03:27:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28746 for ; Tue, 14 Oct 2003 03:27:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jaj-0006ra-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:27:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jai-0006rX-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:27:36 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9E7RY42017787 for ; Tue, 14 Oct 2003 09:27:35 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DS7QH0; Tue, 14 Oct 2003 09:27:53 +0200 Message-ID: <3F8BA564.6000102@ericsson.com> Date: Tue, 14 Oct 2003 09:27:32 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: [MMUSIC] RTSP teleconference 14 october with Agenda 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 Time again for RTSP telecon. Sorry for being late. You are invited to participate in a conference the 14th of October at 18.00 CET. The details to participate. Telephone number: +1 972 583 9950 Participant PIN 74373 Date 10/14/2003 (MM/DD/YYYY) Start Time 18:00 (HH:MM) (CET) The agenda ---------- 1. Opening of meeting. 2. Administrative - Scribe - IETF in Minneapolis * Off-line Meeting? * What to present. 3. Since last meeting (1st of October). a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Text sent to mailing list, please review. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - Text sent to the mailing list e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Text sent to the mailing list. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Needs somebody to write up. g. http://rtsp.org/bug810678 - How to indicate end of media stream - Strawman proposal available from Thomas. For discussion. h. http://rtsp.org/bug770522 - Request to response time is not limited. - Some discussion on mailing list. Sean to write up text. i. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Posted to the mailing list, no comments. Unless comments are received it will be edited in. k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Text posted to the list. No comments received so far. l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Awaiting proposal text from Geetha. m. http://rtsp.org/bug810666 - Removal of SETUP in play state - Proposed to be removed. Message sent to the list. 4. New Issues a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes b. http://rtsp.org/bug795314 - Caching of OPTIONS request 5. Any other business 6. Next Telecon: Proposal Wednesday, 3rd of December. 7. End of meeting Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 03:38:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28912 for ; Tue, 14 Oct 2003 03:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jkr-0004HZ-Vd for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:38:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7c5wt016455 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:38:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jkp-0004Gf-Qc for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28909 for ; Tue, 14 Oct 2003 03:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jkn-0006vM-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Jkm-0006vJ-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jko-0004FN-HY; Tue, 14 Oct 2003 03:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jjx-00045k-2V for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 03:37: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 DAA28906 for ; Tue, 14 Oct 2003 03:37:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jju-0006vG-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:37:06 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jjt-0006vD-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:37:05 -0400 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9E7b542020626 for ; Tue, 14 Oct 2003 09:37:05 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DM7PL0; Tue, 14 Oct 2003 09:40:52 +0200 Message-ID: <3F8BA79F.4090604@ericsson.com> Date: Tue, 14 Oct 2003 09:37:03 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Bug 649272 - Default way of deriving aggregate URL 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, This is the proposed text in regards bug: http://rtsp.org/bug640272 - Default way of deriving aggregate URL The text is from the SETUP method description: "The server {\MUST} generate a session identifier in response to a successful {\SETUP} request, unless a {\SETUP} request to a server includes a session identifier, in which case the server {\MUST} bundle this setup request into the existing session (aggregated session) or return error 459 (Aggregate Operation Not Allowed) (see Section ~\ref{sec:error459}). An Aggregate control URI {\MUST} be used to control an aggregated session. This URI {\MUST} be different from the stream control URIs of the individual media streams included in the aggregate. The Aggregate control URI {\SHOULD} be specified by the session description since there is no general rule for deriving it from the various stream control URIs in the session. If an Aggregate control URI is not specified in the session description, it is probably a indication that non-aggregated control should be used. However a client {\MAY} try to SETUP the session in aggregated control. If the server refuse to aggregate the specified media, the server {\SHALL} use the 459 error code. If the server allows the aggregation, then the client {\MUST} create an URI for aggregate control of the session. This URI {\MUST} contain the servers host address and {\MUST} contain the port, if applicable (e.g. not default port). Once an URI is used to refer to an aggregation for a given session, that URI {\MUST} be used to refer to that aggregation for the duration of the session." Please comment Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 03:41:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28989 for ; Tue, 14 Oct 2003 03:41:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jnj-0004ZD-30 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:41:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9E7f33E017549 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 03:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jni-0004Yj-Lb for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 03:41: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 DAA28948 for ; Tue, 14 Oct 2003 03:40:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Jng-0006wJ-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:41:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Jnf-0006wG-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 03:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Jnh-0004XA-Cm; Tue, 14 Oct 2003 03:41:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9JnV-0004SW-B0 for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 03:40: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 DAA28945 for ; Tue, 14 Oct 2003 03:40:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9JnS-0006w6-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:40:46 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9JnS-0006w3-00 for mmusic@ietf.org; Tue, 14 Oct 2003 03:40:46 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9E7ek42021860 for ; Tue, 14 Oct 2003 09:40:46 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JX11HY; Tue, 14 Oct 2003 09:44:13 +0200 Message-ID: <3F8BA87C.6030100@ericsson.com> Date: Tue, 14 Oct 2003 09:40:44 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: bug 742328 - How to handle PLAY request when at the end of a media clip 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, This is the text proposal for solving this bug: http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip The text belongs to the PLAY method description: "A client desiring to play the media from the beginning {\MUST} send a {\PLAY} request with a \header{Range} header pointing at the beginning, e.g. npt=0-. If a {\PLAY} request is received without a \header{Range} header when media delivery has stopped at the end, the server {\SHOULD} respond with a 457 "Invalid Range" error response. In that response the current pause point in a \header{Range} header {\SHALL} be included." Please comment! Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 07:44:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04702 for ; Tue, 14 Oct 2003 07:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Naw-0007zz-Q5 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 07:44:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EBi6lp030741 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 07:44:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Naw-0007zk-Md for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 07:44: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 HAA04667 for ; Tue, 14 Oct 2003 07:43:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Nav-0001Cp-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 07:44:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Nav-0001Cm-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 07:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Nar-0007xM-LN; Tue, 14 Oct 2003 07:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Na5-0007w6-TE for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 07:43: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 HAA04646 for ; Tue, 14 Oct 2003 07:43:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Na5-0001BP-00 for mmusic@ietf.org; Tue, 14 Oct 2003 07:43:13 -0400 Received: from smtp6.clb.oleane.net ([213.56.31.26]) by ietf-mx with esmtp (Exim 4.12) id 1A9Na4-0001B5-00 for mmusic@ietf.org; Tue, 14 Oct 2003 07:43:12 -0400 Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp6.clb.oleane.net with SMTP id h9EBgf6f024125 for ; Tue, 14 Oct 2003 13:42:41 +0200 Message-ID: <020101c39248$9ec64380$0601a8c0@www.oleane.com> From: "Peter Lewis" To: Date: Tue, 14 Oct 2003 13:45:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01C39259.61FB2720" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [MMUSIC] The 2004 WiFi Voice 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: , C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_01FE_01C39259.61FB2720 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Today, the voice over WLAN market is an extremely small and immature = market but in the longer term, all users of WLAN networks could = eventually find a business case within the context of interoperability = between WLANs and 2.5G and 3G networks.=20 The 2004 WiFi Voice Conference will be held in Paris on May 25 to 28, = 2004.=20 A call for papers has been launched on-line, effective until November = 15, 2003.=20 More details at: http://www.upperside.fr/wifivoice04/wifivoice04intro.htm ------=_NextPart_000_01FE_01C39259.61FB2720 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Today, the voice over WLAN market is an extremely = small and=20 immature market but in the longer term, all users of WLAN networks could = eventually find a business case within the context of interoperability = between=20 WLANs and 2.5G and 3G networks.
The 2004 WiFi Voice = Conference=20 will be held in Paris on May 25 to 28, = 2004.=20

A call for papers has been launched on-line, effective until = November 15, 2003.
More details at:
http://= www.upperside.fr/wifivoice04/wifivoice04intro.htm
------=_NextPart_000_01FE_01C39259.61FB2720-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 13:38:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20844 for ; Tue, 14 Oct 2003 13:38:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9T7T-0004uz-P4 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 13:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EHc3x1018899 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 13:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9T7T-0004uk-LL for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 13:38:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20838 for ; Tue, 14 Oct 2003 13:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9T7R-0005nj-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 13:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9T7R-0005ng-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 13:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9T7R-0004tk-30; Tue, 14 Oct 2003 13:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9T6W-0004bQ-A0 for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 13:37: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 NAA20811 for ; Tue, 14 Oct 2003 13:36:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9T6U-0005n5-00 for mmusic@ietf.org; Tue, 14 Oct 2003 13:37:02 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9T6T-0005n2-00 for mmusic@ietf.org; Tue, 14 Oct 2003 13:37:01 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EHaxSs010797 for ; Tue, 14 Oct 2003 19:36:59 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JQ1XZP; Tue, 14 Oct 2003 19:37:26 +0200 Message-ID: <3F8C3438.9080409@ericsson.com> Date: Tue, 14 Oct 2003 19:36:56 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Bug 771638 - a=range in SDP to indicate live media 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, The below text is proposed for resolving the the following bug: http://rtsp.org/bug771638 - a=range in SDP to indicate live media From Annex C: " Range of Presentation The ``a=range'' attribute defines the total time range of the stored session or an individual media. That Live sessions are non-seekable can also be indicated, while the length of live sessions can be deduced from the ``t'' and ``r'' parameters. The attribute is both a session and a media level attribute. For presentations that contains media streams of the same durations, the range attribute {\SHOULD} only be used at session-level. In case of different length the range attribute {\MUST} be given at media level for all media. If the attribute is present at media level and session level the media level values {\SHALL} be used. The unit is specified first, followed by the value range. The units and their values are as defined in Section \ref{sec:smpte}, \ref{sec:npt} and \ref{sec:clock}. Any open ended range (start-), i.e. without stop range, is of unspecified duration and {\SHALL} be considered as non-seekable content unless this property is overridden. This attribute is defined in ABNF \cite{rfc2234} as: a-range-def = "a" "=" "range" ":" ranges-specifier CRLF Examples: a=range:npt=0-34.4368 a=range:clock=19971113T2115-19971113T2203 Non seekable stream of unknown duration: a=range:npt=0- " Any comments should be given before wednesday the 22nd of October. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 14:04:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21599 for ; Tue, 14 Oct 2003 14:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TWj-0005vQ-BW for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:04:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EI498E022777 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:04:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TWj-0005vI-8b for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:04: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 OAA21552 for ; Tue, 14 Oct 2003 14:03:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TWg-00060R-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:04:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TWg-00060N-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:04:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TWc-0005t9-Pd; Tue, 14 Oct 2003 14:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TWF-0005qj-TO for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 14:03:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21544 for ; Tue, 14 Oct 2003 14:03:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TWD-0005zv-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:03:37 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9TWC-0005zo-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:03:36 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EI3ZSs013784 for ; Tue, 14 Oct 2003 20:03:35 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DTDN0Q; Tue, 14 Oct 2003 20:03:56 +0200 Message-ID: <3F8C3A73.3000508@ericsson.com> Date: Tue, 14 Oct 2003 20:03:31 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is the preliminary minutes for todays telecon. Please comment. RTSP Telecon the 14th of October Participants: Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall. Agenda: 1. Opening of meeting. 2. Administrative - Scribe - IETF in Minneapolis * Off-line Meeting? * What to present. 3. Since last meeting (1st of October). a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Text sent to mailing list, please review. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - Text sent to the mailing list e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Text sent to the mailing list. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Needs somebody to write up. g. http://rtsp.org/bug810678 - How to indicate end of media stream - Strawman proposal available from Thomas. For discussion. h. http://rtsp.org/bug770522 - Request to response time is not limited. - Some discussion on mailing list. Sean to write up text. i. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Posted to the mailing list, no comments. Unless comments are received it will be edited in. k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Text posted to the list. No comments received so far. l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Awaiting proposal text from Geetha. m. http://rtsp.org/bug810666 - Removal of SETUP in play state - Proposed to be removed. Message sent to the list. 4. New Issues a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes b. http://rtsp.org/bug795314 - Caching of OPTIONS request 5. Any other business 6. Next Telecon: Proposal Wednesday, 3rd of December. 7. End of meeting Minutes ------- 1. Meeting was opened. 2. - Magnus volunteered to write the minutes. - IETF meeting in Minneapolis: * Colin will request a conference room for a out-side of normal agenda meeting. A guess of on the number of participants are around 15. * The authors will perform a status update on the specification in the WG session. The current resolutions and open issues will be presented. 3. a. Nothing has happened. b. Await review from the WG. c. Status not changed. d. Await review from the WG. e. Was not sent yet, but will be available directly after meeting. Review comments needed. f. The remaining issue is with implicit closing of the session. The previous meeting has agreement on the functionality but some minor issues around use of "connection" needs resolving. Best way of resolving this is probably to present a specification text proposal. Aravind will take this as a second priority issue. g. Send comments on the document to list. The discussion resolved that this can be divided into several pieces: - We need to document in the RTSP specification regarding RTP what happens when a source times out a SSRC or receives a RTCP BYE for a source. - Using BYE is not suitable way to indicate the end of the stream. The motivation for this can be seen in Thomas proposal. - Look into SIP to see how they have resolved the discrepancies between media and signaling channel. h. Awaits text from Sean. i. This is a later decision when we have received a list of changes that are accurate. j. Unless comments are received by Monday the 20th of October, this resolution will be edited in. Magnus will post a reply to the initial mail pointing out the deadline. k. Will be kept in the text unless comments are review by Wednesday the 22th of October. l. Awaits text. m. Will be edited in unless comments are received by Monday the 20th of October. 4. a. Question raised is: Are there need for a server to announce through SDP or other pre SETUP mechanism which address classes it supports to the client? There was discussion on this topic and the resolution was the following: It should be assumed that a server being possible to find in DNS with a certain address class will support both signaling and media delivery for that address. Thus a RTSP request over TCP/IPv6 will send media using that source IPv6 address. b. The OPTIONS request has some dependency on server state and what content that are addressed. Therefore it seems doubtful that caching of OPTIONS request are possible. In general it seems that the only really cachable RTSP request/response pair is for DESCRIBE. 5. No other business. 6. Preliminary date is the 3rd of December, which is three weeks after the IETF meeting. 7. Meeting was closed. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 14:06:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21776 for ; Tue, 14 Oct 2003 14:06:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TYY-0006PE-Ms for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EI62dq024618 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TYY-0006Oz-Ip for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:06: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 OAA21757 for ; Tue, 14 Oct 2003 14:05:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TYW-00063d-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TYV-00063Y-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:05:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TYX-0006N2-Dy; Tue, 14 Oct 2003 14:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TY5-0006Fv-M8 for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 14:05: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 OAA21681 for ; Tue, 14 Oct 2003 14:05:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TY3-00062K-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:05:31 -0400 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1A9TY2-00062F-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:05:30 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EI5TSs014009 for ; Tue, 14 Oct 2003 20:05:29 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DTD3RC; Tue, 14 Oct 2003 20:05:50 +0200 Message-ID: <3F8C3AE6.7060304@ericsson.com> Date: Tue, 14 Oct 2003 20:05:26 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: bug 742328 - How to handle PLAY request when at the end of a media clip References: <3F8BA87C.6030100@ericsson.com> In-Reply-To: <3F8BA87C.6030100@ericsson.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, Please provide any comments by Wednesday the 22th of October, or the below text will be part of the next version. /Magnus Magnus Westerlund wrote: > Hi, > > This is the text proposal for solving this bug: > > http://rtsp.org/bug742328 - > How to handle PLAY request when at the end of a media clip > > The text belongs to the PLAY method description: > > "A client desiring to play the media from the beginning {\MUST} > send a {\PLAY} request with a \header{Range} header pointing at > the beginning, e.g. npt=0-. If a {\PLAY} request is received > without a \header{Range} header when media delivery has stopped at > the end, the server {\SHOULD} respond with a 457 "Invalid Range" > error response. In that response the current pause point in a > \header{Range} header {\SHALL} be included." > > > Please comment! > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 14:07:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21833 for ; Tue, 14 Oct 2003 14:07:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TZX-0006bI-Fu for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EI73du025316 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TZW-0006aA-G8 for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:07: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 OAA21817 for ; Tue, 14 Oct 2003 14:06:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TZT-00065C-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:06:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TZT-000659-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TZV-0006YP-B2; Tue, 14 Oct 2003 14:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TYs-0006Rx-CK for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 14:06: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 OAA21774 for ; Tue, 14 Oct 2003 14:06:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TYp-00064B-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:06:20 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9TYo-000648-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:06:19 -0400 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EI6HI2020677 for ; Tue, 14 Oct 2003 20:06:17 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 43DTD3WZ; Tue, 14 Oct 2003 20:06:38 +0200 Message-ID: <3F8C3B16.10302@ericsson.com> Date: Tue, 14 Oct 2003 20:06:14 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Bug 649272 - Default way of deriving aggregate URL References: <3F8BA79F.4090604@ericsson.com> In-Reply-To: <3F8BA79F.4090604@ericsson.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, Please provide comments by Wednesday the 22th of October, or this text will be part of the next draft version. Cheers Magnus Magnus Westerlund wrote: > Hi, > > This is the proposed text in regards bug: > > http://rtsp.org/bug640272 - Default way of deriving aggregate URL > > The text is from the SETUP method description: > > "The server {\MUST} generate a session identifier in response to a > successful {\SETUP} request, unless a {\SETUP} request to a server > includes a session identifier, in which case the server {\MUST} > bundle this setup request into the existing session (aggregated > session) or return error 459 (Aggregate Operation Not Allowed) > (see Section ~\ref{sec:error459}). An Aggregate control URI > {\MUST} be used to control an aggregated session. This URI {\MUST} > be different from the stream control URIs of the individual media > streams included in the aggregate. The Aggregate control URI > {\SHOULD} be specified by the session description since there is > no general rule for deriving it from the various stream control > URIs in the session. > > If an Aggregate control URI is not specified in the session > description, it is probably a indication that non-aggregated > control should be used. However a client {\MAY} try to SETUP the > session in aggregated control. If the server refuse to aggregate > the specified media, the server {\SHALL} use the 459 error code. > If the server allows the aggregation, then the client {\MUST} > create an URI for aggregate control of the session. This URI > {\MUST} contain the servers host address and {\MUST} contain the > port, if applicable (e.g. not default port). Once an URI is used > to refer to an aggregation for a given session, that URI {\MUST} > be used to refer to that aggregation for the duration of the > session." > > > Please comment > > > Cheers > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 14:08:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21955 for ; Tue, 14 Oct 2003 14:08:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaX-00075C-Q6 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EI85Pm027218 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:08:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaX-00074n-4s for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:08: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 OAA21887 for ; Tue, 14 Oct 2003 14:07:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TaU-00066u-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TaU-00066r-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaV-00073N-Vs; Tue, 14 Oct 2003 14:08:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TaP-0006xy-Ov for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 14:07: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 OAA21873 for ; Tue, 14 Oct 2003 14:07:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TaN-00066N-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:07:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9TaM-00066J-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:07:54 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EI7rI2020851 for ; Tue, 14 Oct 2003 20:07:53 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JQ18MR; Tue, 14 Oct 2003 20:08:20 +0200 Message-ID: <3F8C3B76.9000505@ericsson.com> Date: Tue, 14 Oct 2003 20:07: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.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Proposal to remove ready-nm state References: <3F7C3A7F.4050107@ericsson.com> In-Reply-To: <3F7C3A7F.4050107@ericsson.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, Unless any comments are received by Monday the 20th of October the proposed changes will be edited in into the next draft version. Cheers Magnus Magnus Westerlund wrote: > Hi, > > I have suggested and got support in yesterdays discussion to remove the > ready-nm state from the RTSP state machine and the functionality > required to make this state work. See below link for further comments on > this. > http://rtsp.org/bug795295 > > Unless anyone has any comment about this within a week or so I will > start removing it from the text. > > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 14:10:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22105 for ; Tue, 14 Oct 2003 14:10:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TcR-0007LF-GZ for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EIA3KO028215 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 14:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TcR-0007L0-1g for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 14:10:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22042 for ; Tue, 14 Oct 2003 14:09:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TcO-000690-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:10:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9TcN-00068x-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 14:09:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TcP-0007JE-Gy; Tue, 14 Oct 2003 14:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9TbY-0007IF-H7 for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 14:09: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 OAA22012 for ; Tue, 14 Oct 2003 14:08:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9TbW-00068c-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:09:06 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9TbV-00068Z-00 for mmusic@ietf.org; Tue, 14 Oct 2003 14:09:05 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9EI94I2021002 for ; Tue, 14 Oct 2003 20:09:04 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JXLSWP; Tue, 14 Oct 2003 20:12:32 +0200 Message-ID: <3F8C3BBD.2020706@ericsson.com> Date: Tue, 14 Oct 2003 20:09:01 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Proposal to remove SETUP and TEARDOWN of individual media streams in PLAY state References: <3F7C3C30.6060906@ericsson.com> In-Reply-To: <3F7C3C30.6060906@ericsson.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, Unless any further comments are received by Monday the 20th of October this change will be edited in. Cheers Magnus Magnus Westerlund wrote: > Hi, > > Another issue that was discussed on yesterdays telecon was the removal > of the part specifying that usage of setup and teardown on individual > media stream in PLAY state is possible. This does not effect the > functionality for: > > - SETUP and Teardown in ready state > - The usage of SETUP to change transport parameters. > - Usage of aggregated Teardown in play state to end session. > > The removal of this functionality will be done in such way that it will > be possible in the future to specify this as extension functionality. > > If no comments are received on this within a week I will start making > these changes. And comments for keeping this functionality should state > a strong use cases for this. > > See also: > http://rtsp.org/bug810666 > > Best Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 15:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24720 for ; Tue, 14 Oct 2003 15:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UXZ-0002H2-UW for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 15:09:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9EJ95di008734 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 15:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UXZ-0002Gn-QO for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 15:09: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 PAA24639 for ; Tue, 14 Oct 2003 15:08:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UXW-0006iZ-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 15:09:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9UXW-0006iW-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 15:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UXU-0002GA-TH; Tue, 14 Oct 2003 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9UWa-00026V-Ge for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 15:08: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 PAA24529 for ; Tue, 14 Oct 2003 15:07:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9UWX-0006hu-00 for mmusic@ietf.org; Tue, 14 Oct 2003 15:08:01 -0400 Received: from smtp3.usherb.ca ([132.210.13.20] helo=smtp3.usherbrooke.ca ident=[pJD22/TMU8vamQpx9v2c1jWHr6stDMdT]) by ietf-mx with esmtp (Exim 4.12) id 1A9UWW-0006hr-00 for mmusic@ietf.org; Tue, 14 Oct 2003 15:08:00 -0400 Received: from kamel (traj1901.gel.usherb.ca [132.210.72.178]) by smtp3.usherbrooke.ca (8.11.6/8.11.6) with ESMTP id h9EJ7hC17428; Tue, 14 Oct 2003 15:07:43 -0400 From: "Joel Tran" To: "'Jonathan Rosenberg'" , "'Peterson, Jon'" Cc: "'Mmusic'" Subject: RE : [MMUSIC] Status of TURN Date: Tue, 14 Oct 2003 15:07:28 -0400 Organization: =?iso-8859-1?Q?Universit=E9_de_Sherbrooke?= Message-ID: <002b01c39286$6c32b000$b248d284@kamel> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <3F859055.2030600@dynamicsoft.com> Importance: Normal X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-4.9, requis 5, BAYES_00 -4.90) Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for your answers concerning TURN. ...J Here are few comments and questions regarding TURN after my first = reading.=20 I would also like to suggest to put the section 9 concerning the = "Protocol Details" before the section 7 concerning the "Server Behavior". In the section 7 & 8, some protocol specific messages are being used with prior introduction on the TURN messages/protocol. It is thus difficult to read = the document. With a proper introduction on the messages of the protocol, = the document will be easier to read. [PAGE 3] =20 A complete solution requires a means by which a client can obtain a transport address from which it can receive media from any peer which can send packets to the public Internet. This can only be accomplished by relaying data though a server that resides on the public Internet. This specification describes Traversal Using Relay NAT (TURN), a protocol that allows a client to obtain IP addresses and ports from such a relay. Joel : Not true. A relay server can reside in a private network (i.e. = full media proxy server/by setting a virtual server provided by NAT routers). [Page 5] TURN Client: A TURN client (also just referred to as a client) is an entity that generates TURN requests. A TURN client can be an end system, such as a Session Initiation Protocol (SIP) [6] User Agent, or can be a network element, such as a Back-to-Back User Agent (B2BUA) SIP server. The TURN protocol will provide the STUN ^^^^ client with IP addresses that route to it from the public Internet. Joel : Did you mean TURN clien or really STUN client? TURN and STUN request/protocol are not the same and thus can not respond to it. [Page 6] When a client is behind a NAT, transport addresses obtained from the local operating system will not be publically routable, and therefore, not useful in these protocols. TURN allows a client to obtain a transport address, from a server on the public Internet, which can be used in protocols meeting the above criteria. However, the transport addresses obtained from TURN servers are not generally ^^^^^^^^^ useful for receiving data from anywhere. Joel : It is ambigious to say generally. This implies that TURN purpose = is not ment to receive data from anywhere but can be used to receive data = from anywhere. [Page 7] A TURN client first discovers the address of a TURN server. This can be preconfigured, or it can be discovered using SRV records [3] This ^^ will allow for different TURN servers for UDP and TCP. Joel : . Missing! Joel : Phrase unclear : This will allow for different TURN servers for = UDP and TCP. Should it be something like : This will allow the use of = different TURN server for UDP and TCP. [Page 8] transport address, PA, in the TURN response. The TURN server is responsible for guaranteeing that packets sent to PA route to the TURN server. Joel : The PA is the TURN Server. How can you send data from PA to the = TURN Server? Should this phase be something like : The TURN Server is then responsible for guaranteeing that packets sent to PA route get to SA. TURN also allows a client to request an odd or even port when one is allocated, and for it to pre-allocate the next higher port. This is useful for securing consecutive ports for usage with the Real Time Transport Protocol (RTP) [5]. Joel : The phrase is unclear, the two cases should be separated to make = it clear: First, request for an odd or event port at the allocation time. Second, Request for a subsequent pre-allocated port. [Section 7.1] Joel: It will proabaly ease the reading of this section if you list and describe all the ERROR-CODE in a table. Furthermore, you can probably do = a use case diagram to ease the reading of this section. [Page 11] The server proceeds to authorize the client. The means for authorization are outside the scope of this specification. It is anticipated that TURN servers will be run by providers that also provide an application service, such as SIP or RTSP. In that case, a user would be authorized to use TURN if they are authorized to use the application service. Joel: You should point to the document which solves the issue concerning = the authorization. [Page 12] the case in TURN. In TURN, the server MUST store the allocated username and password for a duration of at least 30 minutes. Once an Allocate request has been authenticated using that username and password, if the result was an Allocate Error Response, the username and password are discarded. If the result was an Allocate Response, resulting in the creation of a new binding, the username and password become associated with that binding. They can only be used to authenticate Allocate requests sent from the same source transport address in order to refresh or de-allocate that binding. Once the binding is deleted, the username and password are discarded. Joel: How long should the binding in TURN last last? When does the = binding expires? This paragraph is concerning Share secret. It should not = include elements on Allocate Request. This could be move to the next section. Allocate requests are used to obtain an IP address and port that the client can use to receive UDP and TCP packets from any host on the network, even when the client is behind a symmetric NAT. To do this, a TURN server allocates a local transport address, and passes it to the client in an Allocate Response. When the server receives packets on this allocated address, it acts as a relay, and forwards them towards the source of the Allocate request. The server remembers the source transport address where that packet came from, and "locks down". This means that packets sent from the client to the TURN server are forwarded to that address. Joel: "Locks down" what? The phrase is unclear. Locks down the transport address from the source packet. [Page 13] provided by the server. Typically, this will be XXXX, the default TURN port. [[OPEN ISSUE: Can we just use the STUN port?]]. Joel: I wonder if there is some security issue if we use the same port = as STUN. For example, how do we treat purely STUN user without = authentication? How STUN and TURN server can interoperate if they are not merge into a single daemon? The server MUST check the Allocate Request for a MESSAGE-INTEGRITY attribute. If not present, the server generates a Allocate Error Response with an ERROR-CODE attribute with response code 401. Joel: Another table combined with a use case will ease the reading of = this section. [Page 14] determines whether or not it has sufficient capacity to handle a binding that will generate the requested bandwidth. If so, the server looks for the presence of the TRANSPORT-PREFERENCES attribute in the request. If the attribute indicates that an even port is requested, the server attempts to allocate a transport address with an even port. If the attribute indicates that an odd port is requested, the server attempts to allocate a transport address with an odd port. If the attribute indicates that there is no preference for port parity, or if the TRANSPORT-PREFERENCES attribute was absent, the server attempts to allocate a port with either parity. The server MUST NOT allocate ports from the well-known port range (0-1023) and MUST NOT allocate ports from the user registered port range (1024 through 49151). Joel : You should introduce the two elements TURN are looking for at = first and then describing them to ease the reading.=20 [Page 15] Request (TCP or UDP), the source IP address and port of the allocate five-tuple are set to the source IP address and port in the Allocate Request, and the destination IP address and port of the allocate five-tuple are set to the destination IP address and port in the Allocate Request). The protocol in the remote five-tuple is set to the protocol from the Allocate Request. The source IP address of the remote five-tuple is set to the interface from which the base port was allocated. The source port of the remote five-tuple is set to the base port. If the binding was allocated for TCP, the connection on which the Allocate request was received is associated with the allocate five-tuple in the binding. The server MUST remember the one-time username and password used to obtain the binding. Joel: You should probably mention that in the remote tuples, the remote transport address is left blank. Joel : A little suggestion, at the creation of the request message, a 3 = way binding should be created with the one-time username/password, the = allocate and remote five-tuples. When a packet is received at the transport = address, the binding is changed to only the two five-tuples. Joel: There is no case threating the case were, in the two five-tuples, = the protocol of the remote five-tuples does not match the protocol of the allocate five-tuples. For example, what happen when TCP is used in combination with UDP? Personally, I think an error should occur since it = is not the purpose of TURN to make such things as UDP over TCP or TCP over = UDP. [Page 16] The server MUST add a BANDWIDTH attribute to the Allocate Response. This MUST be equal to the attribute from the request, if one was present. Otherwise, it indicates a per-binding cap that the server is placing on the bandwidth usage on each binding. Such caps are needed to prevent against denial-of-service attacks (See Section 10. Joel: Closing ) mising. [Page 17] present, the server checks that this address and port has been pre-allocated by a previous Allocate Request. The only user authorized to allocate a pre-allocated address is the same one that generated the pre-allocation. Note that the one-time usernames for both requests (the pre-allocation and the final allocation) will be different. However, both MUST have been obtained through Shared Secret Requests authenticated as being sent from the same user. Joel: Which error code is sent if the pre-allocated is not generated by = the user who generated the pre-allocation? Once a binding has been created, packets received from the client are generally forwarded to the remote client. However, if the binding is UDP, the client can send subsequent Allocate requests to the TURN server. To determine which packets are for the TURN server, and which need to be relayed, the server looks at the packet. If the packet is shorter than 28 bytes, it is not a TURN request. If it is longer than 28 bytes, the server checks bytes 25-28. If these bytes are equal to the MAGIC-COOKIE, the request is a TURN request. Otherwise, it is a data packet, and is to be relayed. Joel : Why between 25-28? This can be problematic in the future if some extension is added to a TURN messages. I'm not familliar with Ipv6 but = is there some issues with IPv6 adress releam? I understand that this is = within the mecanism to determine which packet are TURN packet and which packet = are relaying packet. All comments are welcome! -----Message d'origine----- De : mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] De la part de Jonathan Rosenberg Envoy=E9 : 9 octobre, 2003 12:44 =C0 : Peterson, Jon Cc : 'Joel Tran'; Mmusic Objet : Re: [MMUSIC] Status of TURN Thanks for the clarification, Jon. To answer Joel's second question - there were some mixups during the=20 submission process last time, and the -02 never got into the archives.=20 I've just resubmitted it so it should be there shortly. I am also hoping to get in a real revision (resulting in a -03=20 version) before the deadline. Please, if you have comments or=20 questions, forward them to me. Thanks, Jonathan R. Peterson, Jon wrote: > The Transport Area Directors understand that this document will=20 > proceed as an individual submission, outside the context of any of the = > working groups in the Transport Area. It is clearly of interest to a=20 > number of these working groups. >=20 > I gather that at least one more revision needs to be undertaken before = > this document will be considered for publication as an RFC, but we're=20 > very interested to see it go forward. >=20 > Jon Peterson > NeuStar, Inc. > (co-AD for Transport) >=20 >=20 >>-----Original Message----- >>From: Joel Tran [mailto:joel_tran@hotmail.com] >>Sent: Tuesday, October 07, 2003 11:08 AM >>To: Jonathan Rosenberg; Mmusic >>Subject: [MMUSIC] Status of TURN >> >> >>Hi Jonathan, >> >>I would like to ask you two little questions concerning TURN. >> >>First, I would like to know what is the exact status of TURN? >>Will it be >>adopted as a Workgroup item of MMUSIC since TURN is refeered=20 >>in various >>documents? >> >>Second, I would like to ask you if there is a reason why the >>lastest version >>of the draft is not on the IETF web and only available throught >>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? >> >>Thanks, >>...J >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> >=20 >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 19:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10350 for ; Tue, 14 Oct 2003 19:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Z1H-0004xR-4L for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 19:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ENu3Fu019053 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 19:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Z1G-0004xE-Vt for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 19:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10289 for ; Tue, 14 Oct 2003 19:55:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Z1E-0003li-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 19:56:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9Z1E-0003lf-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 19:56:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Z1F-0004wZ-Rs; Tue, 14 Oct 2003 19:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9Z0N-0004uN-Bk for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 19:55: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 TAA10229 for ; Tue, 14 Oct 2003 19:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9Z0L-0003ko-00 for mmusic@ietf.org; Tue, 14 Oct 2003 19:55:05 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1A9Z0K-0003jf-00 for mmusic@ietf.org; Tue, 14 Oct 2003 19:55:04 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9ENsMPa067754; Tue, 14 Oct 2003 16:54:23 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Oct 2003 16:54:22 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17B7F@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , IETF MMUSIC WG Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Date: Tue, 14 Oct 2003 16:54:22 -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: , On item g: - Look into SIP to see how they have resolved the discrepancies between media and signaling channel. Could someone fammiliar with SIP help me out here: I need to know what method of SIP to look, is it SIP BYE method by any chance? (I saw that SIP has a BYE method to terminate the call in the signalling channel. ) thanks, thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Tuesday, October 14, 2003 11:04 AM To: IETF MMUSIC WG Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Hi, Here is the preliminary minutes for todays telecon. Please comment. RTSP Telecon the 14th of October Participants: Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall. Agenda: 1. Opening of meeting. 2. Administrative - Scribe - IETF in Minneapolis * Off-line Meeting? * What to present. 3. Since last meeting (1st of October). a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Text sent to mailing list, please review. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - Text sent to the mailing list e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Text sent to the mailing list. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Needs somebody to write up. g. http://rtsp.org/bug810678 - How to indicate end of media stream - Strawman proposal available from Thomas. For discussion. h. http://rtsp.org/bug770522 - Request to response time is not limited. - Some discussion on mailing list. Sean to write up text. i. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Posted to the mailing list, no comments. Unless comments are received it will be edited in. k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Text posted to the list. No comments received so far. l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Awaiting proposal text from Geetha. m. http://rtsp.org/bug810666 - Removal of SETUP in play state - Proposed to be removed. Message sent to the list. 4. New Issues a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes b. http://rtsp.org/bug795314 - Caching of OPTIONS request 5. Any other business 6. Next Telecon: Proposal Wednesday, 3rd of December. 7. End of meeting Minutes ------- 1. Meeting was opened. 2. - Magnus volunteered to write the minutes. - IETF meeting in Minneapolis: * Colin will request a conference room for a out-side of normal agenda meeting. A guess of on the number of participants are around 15. * The authors will perform a status update on the specification in the WG session. The current resolutions and open issues will be presented. 3. a. Nothing has happened. b. Await review from the WG. c. Status not changed. d. Await review from the WG. e. Was not sent yet, but will be available directly after meeting. Review comments needed. f. The remaining issue is with implicit closing of the session. The previous meeting has agreement on the functionality but some minor issues around use of "connection" needs resolving. Best way of resolving this is probably to present a specification text proposal. Aravind will take this as a second priority issue. g. Send comments on the document to list. The discussion resolved that this can be divided into several pieces: - We need to document in the RTSP specification regarding RTP what happens when a source times out a SSRC or receives a RTCP BYE for a source. - Using BYE is not suitable way to indicate the end of the stream. The motivation for this can be seen in Thomas proposal. - Look into SIP to see how they have resolved the discrepancies between media and signaling channel. h. Awaits text from Sean. i. This is a later decision when we have received a list of changes that are accurate. j. Unless comments are received by Monday the 20th of October, this resolution will be edited in. Magnus will post a reply to the initial mail pointing out the deadline. k. Will be kept in the text unless comments are review by Wednesday the 22th of October. l. Awaits text. m. Will be edited in unless comments are received by Monday the 20th of October. 4. a. Question raised is: Are there need for a server to announce through SDP or other pre SETUP mechanism which address classes it supports to the client? There was discussion on this topic and the resolution was the following: It should be assumed that a server being possible to find in DNS with a certain address class will support both signaling and media delivery for that address. Thus a RTSP request over TCP/IPv6 will send media using that source IPv6 address. b. The OPTIONS request has some dependency on server state and what content that are addressed. Therefore it seems doubtful that caching of OPTIONS request are possible. In general it seems that the only really cachable RTSP request/response pair is for DESCRIBE. 5. No other business. 6. Preliminary date is the 3rd of December, which is three weeks after the IETF meeting. 7. Meeting was closed. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 14 23:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15051 for ; Tue, 14 Oct 2003 23:03:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bwH-0007Mj-3k for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 23:03:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F334RD028307 for mmusic-archive@odin.ietf.org; Tue, 14 Oct 2003 23:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bwG-0007MU-FD for mmusic-web-archive@optimus.ietf.org; Tue, 14 Oct 2003 23:03: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 XAA15037 for ; Tue, 14 Oct 2003 23:02:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bwC-0005aw-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 23:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9bwC-0005at-00 for mmusic-web-archive@ietf.org; Tue, 14 Oct 2003 23:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bwE-0007M2-2H; Tue, 14 Oct 2003 23:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9bw5-0007Lr-7g for mmusic@optimus.ietf.org; Tue, 14 Oct 2003 23:02: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 XAA15033 for ; Tue, 14 Oct 2003 23:02:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9bw1-0005ap-00 for mmusic@ietf.org; Tue, 14 Oct 2003 23:02:49 -0400 Received: from [220.117.193.11] (helo=mail.nextreaming.com) by ietf-mx with esmtp (Exim 4.12) id 1A9bvz-0005al-00 for mmusic@ietf.org; Tue, 14 Oct 2003 23:02:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Subject: RE: [MMUSIC] RTSP: Bug 771638 - a=range in SDP to indicate live media MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 12:02:13 +0900 Message-ID: Thread-Topic: [MMUSIC] RTSP: Bug 771638 - a=range in SDP to indicate live media Thread-Index: AcOSef1Fj2jquO/WQq2XAtME1gwbCwATEbPA From: "Jae-Hwan Kim" To: "Magnus Westerlund" , "IETF MMUSIC WG" Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Just a simple question regarding range header although it is far from an live indicating. I saw an example, 2 range headers at session-level SDP because the original content contains a=3Drange in its hinted SDP area: the first = one is 'a=3Drange:npt=3D0-620' server made and the other is 'a=3Drange:npt=3D0-300'(or npt=3D0-) originally from the server; in case = of two different range attributes exist. Almost all hinted server just seems to get and forward SDP and RTP data. How can we, as a player, understand this SDP?=20 Just I think the possible and right behavior is as followings: 1) If there are two or more a=3Drange header at a session-level or media-level, the maximum one shall be used. 2) But if there is npt=3D0-, it means also this content is not seekable. I would appreciate it for your advice. Cheers, Jae-Hwan > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Wednesday, October 15, 2003 2:37 AM > To: IETF MMUSIC WG > Subject: [MMUSIC] RTSP: Bug 771638 - a=3Drange in SDP to=20 > indicate live media >=20 >=20 > Hi, >=20 > The below text is proposed for resolving the the following bug: >=20 > http://rtsp.org/bug771638 - a=3Drange in SDP to indicate live media >=20 > From Annex C: >=20 > " > Range of Presentation >=20 > The ``a=3Drange'' attribute defines the total time range of the=20 > stored session or an individual media. That Live sessions are=20 > non-seekable can also be indicated, while the length of live=20 > sessions can be deduced from the ``t'' and ``r'' parameters. >=20 > The attribute is both a session and a media level attribute.=20 > For presentations that contains media streams of the same=20 > durations, the range attribute {\SHOULD} only be used at=20 > session-level. In case of different length the range=20 > attribute {\MUST} be given at media level for all media. If=20 > the attribute is present at media level and session level the=20 > media level values {\SHALL} be used. >=20 > The unit is specified first, followed by the value range. The=20 > units and their values are as defined in Section=20 > \ref{sec:smpte}, \ref{sec:npt} and \ref{sec:clock}. Any open=20 > ended range (start-), i.e. without stop range, is of=20 > unspecified duration and {\SHALL} be considered as=20 > non-seekable content unless this property is overridden. >=20 >=20 > This attribute is defined in ABNF \cite{rfc2234} as: >=20 > a-range-def =3D "a" "=3D" "range" ":" ranges-specifier CRLF >=20 >=20 >=20 > Examples: >=20 > a=3Drange:npt=3D0-34.4368 > a=3Drange:clock=3D19971113T2115-19971113T2203 > Non seekable stream of unknown duration: > a=3Drange:npt=3D0- >=20 > " >=20 > Any comments should be given before wednesday the 22nd of October. >=20 > Cheers >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 00:54:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17158 for ; Wed, 15 Oct 2003 00:54:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dff-0004gi-G5 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 00:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F4s3Cl018017 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 00:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dff-0004gU-7P for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 00:54:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17148 for ; Wed, 15 Oct 2003 00:53:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dfc-0006Q1-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 00:54:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9dfb-0006Py-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 00:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dfd-0004fu-My; Wed, 15 Oct 2003 00:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9dfE-0004fV-28 for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 00:53: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 AAA17135 for ; Wed, 15 Oct 2003 00:53:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9dfB-0006PU-00 for mmusic@ietf.org; Wed, 15 Oct 2003 00:53:33 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1A9dfA-0006Ow-00 for mmusic@ietf.org; Wed, 15 Oct 2003 00:53:32 -0400 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9F4r2Ug000900; Wed, 15 Oct 2003 00:53:02 -0400 (EDT) Message-ID: <3F8CD2A5.5060703@dynamicsoft.com> Date: Wed, 15 Oct 2003 00:52:53 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: "'Magnus Westerlund'" , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 References: <72263E8E8622D611975C0002B32C19D805A17B7F@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17B7F@misty.packetvideo.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 Yes, SIP BYE is used to terminate the call, which also results in the termination of the media sessions. -Jonathan R. Thomas Zeng wrote: > On item g: > > - Look into SIP to see how they have resolved the discrepancies > between media and signaling channel. > > Could someone fammiliar with SIP help me out here: I need to know what > method of SIP to look, is it SIP BYE method by any chance? > > (I saw that SIP has a BYE method to terminate the call in the signalling > channel. ) > > thanks, > thomas > > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 14, 2003 11:04 AM > To: IETF MMUSIC WG > Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 > > > Hi, > > Here is the preliminary minutes for todays telecon. Please comment. > > RTSP Telecon the 14th of October > > Participants: > Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall. > > Agenda: > > 1. Opening of meeting. > > 2. Administrative > - Scribe > - IETF in Minneapolis > * Off-line Meeting? > * What to present. > > 3. Since last meeting (1st of October). > a. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > > b. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Text sent to mailing list, please review. > > c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. > - Needs text > > d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL > - Text sent to the mailing list > > e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media > - Text sent to the mailing list. > > f. http://rtsp.org/bug531189 - How does REDIRECT method work > - Needs somebody to write up. > > g. http://rtsp.org/bug810678 - How to indicate end of media stream > - Strawman proposal available from Thomas. For discussion. > > h. http://rtsp.org/bug770522 - Request to response time is not limited. > - Some discussion on mailing list. Sean to write up text. > > i. http://rtsp.org/bug810681 - The updated specification version number > - Awaiting investigation results regarding changes by Aravind. > > j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state > - Posted to the mailing list, no comments. Unless comments are > received it will be edited in. > > k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP > - Text posted to the list. No comments received so far. > > l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters > - Awaiting proposal text from Geetha. > > m. http://rtsp.org/bug810666 - Removal of SETUP in play state > - Proposed to be removed. Message sent to the list. > > 4. New Issues > > a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address > classes > > b. http://rtsp.org/bug795314 - Caching of OPTIONS request > > 5. Any other business > > 6. Next Telecon: Proposal Wednesday, 3rd of December. > > 7. End of meeting > > Minutes > ------- > > 1. Meeting was opened. > > 2. - Magnus volunteered to write the minutes. > > - IETF meeting in Minneapolis: > * Colin will request a conference room for a out-side of normal > agenda meeting. A guess of on the number of participants are > around 15. > > * The authors will perform a status update on the specification in > the WG session. The current resolutions and open issues will be > presented. > > 3. > > a. Nothing has happened. > > b. Await review from the WG. > > c. Status not changed. > > d. Await review from the WG. > > e. Was not sent yet, but will be available directly after meeting. > Review comments needed. > > f. The remaining issue is with implicit closing of the session. The > previous meeting has agreement on the functionality but some minor > issues around use of "connection" needs resolving. Best way of > resolving this is probably to present a specification text proposal. > Aravind will take this as a second priority issue. > > g. Send comments on the document to list. The discussion resolved that > this can be divided into several pieces: > > - We need to document in the RTSP specification regarding RTP what > happens when a source times out a SSRC or receives a RTCP BYE for a > source. > > - Using BYE is not suitable way to indicate the end of the stream. > The motivation for this can be seen in Thomas proposal. > > - Look into SIP to see how they have resolved the discrepancies > between media and signaling channel. > > h. Awaits text from Sean. > > i. This is a later decision when we have received a list of changes that > are accurate. > > j. Unless comments are received by Monday the 20th of October, this > resolution will be edited in. Magnus will post a reply to the initial > mail pointing out the deadline. > > k. Will be kept in the text unless comments are review by Wednesday the > 22th of October. > > l. Awaits text. > > m. Will be edited in unless comments are received by Monday the 20th of > October. > > 4. > a. Question raised is: Are there need for a server to announce through > SDP or other pre SETUP mechanism which address classes it supports to > the client? > > There was discussion on this topic and the resolution was the > following: > > It should be assumed that a server being possible to find in DNS with > a certain address class will support both signaling and media > delivery for that address. Thus a RTSP request over TCP/IPv6 will > send media using that source IPv6 address. > > b. The OPTIONS request has some dependency on server state and what > content that are addressed. Therefore it seems doubtful that caching of > OPTIONS request are possible. In general it seems that the only > really cachable RTSP request/response pair is for DESCRIBE. > > 5. No other business. > > 6. Preliminary date is the 3rd of December, which is three weeks after > the IETF meeting. > > 7. Meeting was closed. > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 03:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17509 for ; Wed, 15 Oct 2003 03:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9feb-0005wa-S3 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 03:01:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F715jb022844 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 03:01:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9feb-0005wN-5c for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 03:01: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 DAA17488 for ; Wed, 15 Oct 2003 03:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9feX-00008Y-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 03:01:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9feW-00008V-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 03:01:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9feY-0005vv-MV; Wed, 15 Oct 2003 03:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fdx-0005rs-5S for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 03: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 DAA17485 for ; Wed, 15 Oct 2003 03:00:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fdt-00008K-00 for mmusic@ietf.org; Wed, 15 Oct 2003 03:00:21 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9fds-00008G-00 for mmusic@ietf.org; Wed, 15 Oct 2003 03:00:20 -0400 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F70II2004436; Wed, 15 Oct 2003 09:00:18 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JQ2Q40; Wed, 15 Oct 2003 09:00:47 +0200 Message-ID: <3F8CF07E.5080702@ericsson.com> Date: Wed, 15 Oct 2003 09:00:14 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Thomas Zeng , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 References: <72263E8E8622D611975C0002B32C19D805A17B7F@misty.packetvideo.com> <3F8CD2A5.5060703@dynamicsoft.com> In-Reply-To: <3F8CD2A5.5060703@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 Thanks Jonathan, However this is more regarding the other way around. How does SIP handle if it receives RTCP BYE or times out a SSRC in an RTP session part of the currnet media session? Cheers Magnus Jonathan Rosenberg wrote: > Yes, SIP BYE is used to terminate the call, which also results in the > termination of the media sessions. > > -Jonathan R. > > Thomas Zeng wrote: > >> On item g: >> >> - Look into SIP to see how they have resolved the discrepancies >> between media and signaling channel. >> >> Could someone fammiliar with SIP help me out here: I need to know what >> method of SIP to look, is it SIP BYE method by any chance? >> >> (I saw that SIP has a BYE method to terminate the call in the signalling >> channel. ) >> >> thanks, >> thomas >> >> >> >> -----Original Message----- >> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >> Sent: Tuesday, October 14, 2003 11:04 AM >> To: IETF MMUSIC WG >> Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 >> >> >> Hi, >> >> Here is the preliminary minutes for todays telecon. Please comment. >> >> RTSP Telecon the 14th of October >> >> Participants: >> Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall. >> >> Agenda: >> >> 1. Opening of meeting. >> >> 2. Administrative >> - Scribe >> - IETF in Minneapolis >> * Off-line Meeting? >> * What to present. >> >> 3. Since last meeting (1st of October). >> a. http://rtsp.org/bug507882 - RTP timestamp and pause >> - Aravind to write up text >> >> b. http://rtsp.org/bug742328 - How to handle PLAY request when at the >> end of a media clip >> - Text sent to mailing list, please review. >> >> c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. >> - Needs text >> >> d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL >> - Text sent to the mailing list >> >> e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media >> - Text sent to the mailing list. >> >> f. http://rtsp.org/bug531189 - How does REDIRECT method work >> - Needs somebody to write up. >> >> g. http://rtsp.org/bug810678 - How to indicate end of media stream >> - Strawman proposal available from Thomas. For discussion. >> >> h. http://rtsp.org/bug770522 - Request to response time is not limited. >> - Some discussion on mailing list. Sean to write up text. >> >> i. http://rtsp.org/bug810681 - The updated specification version >> number >> - Awaiting investigation results regarding changes by Aravind. >> >> j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state >> - Posted to the mailing list, no comments. Unless comments are >> received it will be edited in. >> >> k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP >> - Text posted to the list. No comments received so far. >> >> l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters >> - Awaiting proposal text from Geetha. >> >> m. http://rtsp.org/bug810666 - Removal of SETUP in play state >> - Proposed to be removed. Message sent to the list. >> >> 4. New Issues >> >> a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible >> address classes >> >> b. http://rtsp.org/bug795314 - Caching of OPTIONS request >> >> 5. Any other business >> >> 6. Next Telecon: Proposal Wednesday, 3rd of December. >> >> 7. End of meeting >> >> Minutes >> ------- >> >> 1. Meeting was opened. >> >> 2. - Magnus volunteered to write the minutes. >> >> - IETF meeting in Minneapolis: >> * Colin will request a conference room for a out-side of normal >> agenda meeting. A guess of on the number of participants are >> around 15. >> >> * The authors will perform a status update on the specification in >> the WG session. The current resolutions and open issues will be >> presented. >> >> 3. >> >> a. Nothing has happened. >> >> b. Await review from the WG. >> >> c. Status not changed. >> >> d. Await review from the WG. >> >> e. Was not sent yet, but will be available directly after meeting. >> Review comments needed. >> >> f. The remaining issue is with implicit closing of the session. The >> previous meeting has agreement on the functionality but some minor >> issues around use of "connection" needs resolving. Best way of >> resolving this is probably to present a specification text proposal. >> Aravind will take this as a second priority issue. >> >> g. Send comments on the document to list. The discussion resolved that >> this can be divided into several pieces: >> >> - We need to document in the RTSP specification regarding RTP what >> happens when a source times out a SSRC or receives a RTCP BYE for a >> source. >> >> - Using BYE is not suitable way to indicate the end of the stream. >> The motivation for this can be seen in Thomas proposal. >> >> - Look into SIP to see how they have resolved the discrepancies >> between media and signaling channel. >> >> h. Awaits text from Sean. >> >> i. This is a later decision when we have received a list of changes that >> are accurate. >> >> j. Unless comments are received by Monday the 20th of October, this >> resolution will be edited in. Magnus will post a reply to the initial >> mail pointing out the deadline. >> >> k. Will be kept in the text unless comments are review by Wednesday the >> 22th of October. >> >> l. Awaits text. >> >> m. Will be edited in unless comments are received by Monday the 20th of >> October. >> >> 4. >> a. Question raised is: Are there need for a server to announce through >> SDP or other pre SETUP mechanism which address classes it supports to >> the client? >> >> There was discussion on this topic and the resolution was the >> following: >> >> It should be assumed that a server being possible to find in DNS with >> a certain address class will support both signaling and media >> delivery for that address. Thus a RTSP request over TCP/IPv6 will >> send media using that source IPv6 address. >> >> b. The OPTIONS request has some dependency on server state and what >> content that are addressed. Therefore it seems doubtful that caching of >> OPTIONS request are possible. In general it seems that the only >> really cachable RTSP request/response pair is for DESCRIBE. >> >> 5. No other business. >> >> 6. Preliminary date is the 3rd of December, which is three weeks after >> the IETF meeting. >> >> 7. Meeting was closed. >> >> >> > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 03:07:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17774 for ; Wed, 15 Oct 2003 03:07:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fkO-0006j5-Ep for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 03:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F774Ph025855 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 03:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fkO-0006iw-3g for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 03:07: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 DAA17755 for ; Wed, 15 Oct 2003 03:06:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fkJ-0000Di-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 03:06:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9fkJ-0000Df-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 03:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fkM-0006h1-4H; Wed, 15 Oct 2003 03:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9fjf-0006da-2R for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 03:06: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 DAA17695 for ; Wed, 15 Oct 2003 03:06:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9fja-0000Cm-00 for mmusic@ietf.org; Wed, 15 Oct 2003 03:06:14 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1A9fja-0000Ci-00 for mmusic@ietf.org; Wed, 15 Oct 2003 03:06:14 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9F76EI2006997; Wed, 15 Oct 2003 09:06:14 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JXRSA1; Wed, 15 Oct 2003 09:09:44 +0200 Message-ID: <3F8CF1E1.30905@ericsson.com> Date: Wed, 15 Oct 2003 09:06:09 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jae-Hwan Kim CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Bug 771638 - a=range in SDP to indicate live media References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jae-Hwan, I am not certain I understand your concern. You have cases where the SDP has the following attributes in it: a=range:npt=0-620 a=range:npt=0-300 In my opinion this is an erroneous SDP. The server creating this SDP has made a mistake. The only concern I have with limiting the SDP attribute to only contain a single range is that the following case is not possible to express: Range: npt=0-300, npt=450-600 That is possible to express in the RTSP range header. And is maybe even more useful when used with "clock" to inform what parts that are available of yesterdays recorded TV programs. If the above was not what you meant, please clarify. Cheers Magnus Jae-Hwan Kim wrote: > Hi, > > Just a simple question regarding range header although it is far from an > live indicating. > I saw an example, 2 range headers at session-level SDP because the > original content contains a=range in its hinted SDP area: the first one > is 'a=range:npt=0-620' server made and the other is > 'a=range:npt=0-300'(or npt=0-) originally from the server; in case of > two different range attributes exist. Almost all hinted server just > seems to get and forward SDP and RTP data. > > How can we, as a player, understand this SDP? > Just I think the possible and right behavior is as followings: > 1) If there are two or more a=range header at a session-level or > media-level, the maximum one shall be used. > 2) But if there is npt=0-, it means also this content is not seekable. > > I would appreciate it for your advice. > > Cheers, > Jae-Hwan > > > >>-----Original Message----- >>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>Sent: Wednesday, October 15, 2003 2:37 AM >>To: IETF MMUSIC WG >>Subject: [MMUSIC] RTSP: Bug 771638 - a=range in SDP to >>indicate live media >> >> >>Hi, >> >>The below text is proposed for resolving the the following bug: >> >>http://rtsp.org/bug771638 - a=range in SDP to indicate live media >> >> From Annex C: >> >>" >>Range of Presentation >> >>The ``a=range'' attribute defines the total time range of the >>stored session or an individual media. That Live sessions are >>non-seekable can also be indicated, while the length of live >>sessions can be deduced from the ``t'' and ``r'' parameters. >> >>The attribute is both a session and a media level attribute. >>For presentations that contains media streams of the same >>durations, the range attribute {\SHOULD} only be used at >>session-level. In case of different length the range >>attribute {\MUST} be given at media level for all media. If >>the attribute is present at media level and session level the >>media level values {\SHALL} be used. >> >>The unit is specified first, followed by the value range. The >>units and their values are as defined in Section >>\ref{sec:smpte}, \ref{sec:npt} and \ref{sec:clock}. Any open >>ended range (start-), i.e. without stop range, is of >>unspecified duration and {\SHALL} be considered as >>non-seekable content unless this property is overridden. >> >> >>This attribute is defined in ABNF \cite{rfc2234} as: >> >>a-range-def = "a" "=" "range" ":" ranges-specifier CRLF >> >> >> >>Examples: >> >> a=range:npt=0-34.4368 >> a=range:clock=19971113T2115-19971113T2203 >> Non seekable stream of unknown duration: >> a=range:npt=0- >> >>" >> >>Any comments should be given before wednesday the 22nd of October. >> >>Cheers >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 05:57:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22725 for ; Wed, 15 Oct 2003 05:57:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iOu-0001P6-Ok for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 05:57:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F9v4XX005385 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 05:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iOu-0001OP-Dm for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 05:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22671 for ; Wed, 15 Oct 2003 05:56:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iOq-00026g-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 05:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9iOq-00026d-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 05:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iOt-0001NJ-0W; Wed, 15 Oct 2003 05:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iOf-0001Ld-4u for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 05:56: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 FAA22647; Wed, 15 Oct 2003 05:56:38 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iOa-000264-00; Wed, 15 Oct 2003 05:56:44 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A9iOZ-00025w-00; Wed, 15 Oct 2003 05:56:43 -0400 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F9ugd08787; Wed, 15 Oct 2003 12:56:42 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 12:56:42 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:41 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:56:39 +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" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 12:56:38 +0300 Message-ID: <2BF0AD29BC31FE46B788773211440431038165E6@trebe003.europe.nokia.com> Thread-Topic: Multicast Session/Service/etc discovery & announcement Thread-Index: AcOS9gsoVA8cELvBTy+SKp1fLS1jzg== To: , , , , Cc: X-OriginalArrivalTime: 15 Oct 2003 09:56:39.0866 (UTC) FILETIME=[A11B89A0:01C39302] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Multicast Session/Service/etc discovery & announcement Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does our current effort to summarize multicast service discovery = requirements in MMUSIC meet your needs? Internet Media Guide requirements: = http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt Clearly, exchanging/announcing session/etc parameters effects joining = (SSM and ASM), involves security risks and enable multicast content = services - like streaming media and file delivery. So any comments, = criticisms, ideas and beers are welcome. (Speaking of service = announcements, does Minneapolis offer the same excellent range of Ales = as San Francisco?) Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 05:59:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22932 for ; Wed, 15 Oct 2003 05:59:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iQq-0001tF-0L for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 05:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9F9x37a007259 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 05:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iQp-0001ss-Ow for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 05:59:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22884 for ; Wed, 15 Oct 2003 05:58:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iQl-0002AS-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 05:58:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9iQk-0002AN-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 05:58:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iQn-0001on-Ut; Wed, 15 Oct 2003 05:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9iQ1-0001h9-RU for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 05:58: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 FAA22812 for ; Wed, 15 Oct 2003 05:58:04 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9iPy-00028C-00 for mmusic@ietf.org; Wed, 15 Oct 2003 05:58:10 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1A9iPx-000289-00 for mmusic@ietf.org; Wed, 15 Oct 2003 05:58:09 -0400 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9F9w9d10478 for ; Wed, 15 Oct 2003 12:58:09 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 15 Oct 2003 12:58:06 +0300 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:58:06 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 15 Oct 2003 12:58:06 +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" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Oct 2003 12:58:05 +0300 Message-ID: Thread-Topic: Service/Session Announcement for Multicast Apps Thread-Index: AcOS8wr7v6GjFmLwTK6ok2hiYbiUAQ== To: , X-OriginalArrivalTime: 15 Oct 2003 09:58:06.0185 (UTC) FILETIME=[D48EC590:01C39302] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Service/Session Announcement for Multicast Apps Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does anyone have a problem with a new and better announcement protocol = than SAP? We need a few things which SAP doesn't handle too well, which is one of = the things covered by the Internet Media Guide effort in MMUSIC: = http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt I guess anyone involved in applications/services over multicast could be = interested, especially where point-to-point isn't desirable. I wanted to get an idea of any strong opinions before I stick out head = and propose a real protocol task for MMUSIC next month. Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 08:30:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27069 for ; Wed, 15 Oct 2003 08:30:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kmz-0002VB-0H for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 08:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FCU4Iw009611 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 08:30:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kmy-0002Uw-ON for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 08:30: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 IAA27063 for ; Wed, 15 Oct 2003 08:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9kmx-0003pF-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 08:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9kmw-0003pC-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 08:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9kmw-0002UT-2K; Wed, 15 Oct 2003 08:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9km3-0002Su-PI for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 08:29:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27018 for ; Wed, 15 Oct 2003 08:28:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9km2-0003oL-00 for mmusic@ietf.org; Wed, 15 Oct 2003 08:29:06 -0400 Received: from mail.icst.pku.cn ([162.105.163.119] helo=mail.icst.pku.edu.cn) by ietf-mx with smtp (Exim 4.12) id 1A9km1-0003o8-00 for mmusic@ietf.org; Wed, 15 Oct 2003 08:29:05 -0400 Received: (qmail 10438 invoked from network); 15 Oct 2003 12:33:04 -0000 Received: from unknown (HELO siduanfeng) (162.105.163.99) by mail.icst.pku.cn with SMTP; 15 Oct 2003 12:33:04 -0000 Message-ID: <02b401c39317$e3d7afc0$7a01a8c0@siduanfeng> From: "siduanfeng" To: Date: Wed, 15 Oct 2003 20:28:50 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: base64 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 Content-Transfer-Encoding: base64 Subject: [MMUSIC] About SIP research fields for Ph.D theme Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SSBhbSBhIFBoLkQgY2FuZGlkYXRlIG9mIFBla2luZyBVbml2ZXJzaXR5IGluIENoaW5hLiBJIHdh bnQgdG8gY2hvaWNlIGEgYXBwcm9wcmlhdGUgcmVzZWFyY2ggZmllbGQgKFNJUCBhbmQgcmVsYXRp dmVkIClmb3IgbXkgUGguRCB0aGVtZSwgYW55b25lIGNhbiBnaXZlIG1lIHNvbWUgc3VnZ2VzdGlv bj8gQW5kIGFueW9uZSBjYW4gdGVsbCBtZSBzb21lIHByb21pc2luZyBvciBwb3AgcmVzZWFyY2gg ZGlyZWN0aW9uIGFib3V0IFNJUC4gVGhhbmtzLg== _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 08:47:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27898 for ; Wed, 15 Oct 2003 08:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l3T-0003jQ-QK for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 08:47:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FCl75f014338 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 08:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l3T-0003jB-M9 for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 08:47: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 IAA27835 for ; Wed, 15 Oct 2003 08:46:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9l3S-0003zu-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 08:47:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9l3R-0003zr-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 08:47:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l3N-0003iC-Tw; Wed, 15 Oct 2003 08:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9l2f-0003gK-PL for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 08:46: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 IAA27704; Wed, 15 Oct 2003 08:46:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9l2e-0003zX-00; Wed, 15 Oct 2003 08:46:16 -0400 Received: from protactinium.btinternet.com ([194.73.73.176]) by ietf-mx with esmtp (Exim 4.12) id 1A9l2d-0003zT-00; Wed, 15 Oct 2003 08:46:15 -0400 Received: from host213-122-132-61.in-addr.btopenworld.com ([213.122.132.61] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #23) id 1A9l2J-0003OP-00; Wed, 15 Oct 2003 13:45:56 +0100 Message-ID: <003301c3931a$781e72c0$0200000a@tkw> From: "Pete Cordell" To: "Peterson, Jon" , "Mmusic" Cc: , "Jonathan Rosenberg" References: Subject: Re: [MMUSIC] Status of TURN Date: Wed, 15 Oct 2003 13:47:09 +0100 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Dear Jon, I'm very surprised to see that TURN is being encouraged to be put forward as an individual submission. We believe that TURN has major security flaws, is incomplete, and there are better ways of achieving Symmetric NAT traversal. Suggesting it should become an RFC without debate and full consideration would be wrong. If you remember, TURN was just one of the candidates put forward as a pre-Midcom solution that at that time was put aside in favour of developing a consensus protocol. Despite our commitment, consensus wasn't reached, mainly due to the amount of effort that was being put into SIP (RFC3261) by other important stake holders. We feel that to arbitrarily promote TURN at this time is short cutting the consensus making process. Surely, if there is sufficient interest in a standard of this nature, the correct way forward is to assign it as a work item in a suitable group and re-start the consensus process. If so, we remain willing to help with time, resource and considerable technical know-how. Several significant developments have meant the world of Symmetric NAT traversal has advanced considerably since the pre-Midcom days. Regards, Pete. ============================================= Pete Cordell Ridgeway ============================================= ----- Original Message ----- From: "Peterson, Jon" To: "'Joel Tran'" ; "Jonathan Rosenberg" ; "Mmusic" Sent: 09 October 2003 17:08 Subject: RE: [MMUSIC] Status of TURN > > The Transport Area Directors understand that this document will proceed as > an individual submission, outside the context of any of the working groups > in the Transport Area. It is clearly of interest to a number of these > working groups. > > I gather that at least one more revision needs to be undertaken before this > document will be considered for publication as an RFC, but we're very > interested to see it go forward. > > Jon Peterson > NeuStar, Inc. > (co-AD for Transport) > > > -----Original Message----- > > From: Joel Tran [mailto:joel_tran@hotmail.com] > > Sent: Tuesday, October 07, 2003 11:08 AM > > To: Jonathan Rosenberg; Mmusic > > Subject: [MMUSIC] Status of TURN > > > > > > Hi Jonathan, > > > > I would like to ask you two little questions concerning TURN. > > > > First, I would like to know what is the exact status of TURN? > > Will it be > > adopted as a Workgroup item of MMUSIC since TURN is refeered > > in various > > documents? > > > > Second, I would like to ask you if there is a reason why the > > lastest version > > of the draft is not on the IETF web and only available throught > > http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > > > > Thanks, > > ...J > > > > _______________________________________________ > > 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 exim@www1.ietf.org Wed Oct 15 11:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04855 for ; Wed, 15 Oct 2003 11:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9naC-0005TI-3Q for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 11:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9FFT4Sp021031 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 11:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9naB-0005T7-V1 for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 11:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04806 for ; Wed, 15 Oct 2003 11:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9naA-0005xc-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 11:29:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9na9-0005xZ-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 11:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9naA-0005SK-B9; Wed, 15 Oct 2003 11:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9nZg-0005Lg-PZ for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 11:28: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 LAA04704 for ; Wed, 15 Oct 2003 11:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9nZf-0005vM-00 for mmusic@ietf.org; Wed, 15 Oct 2003 11:28:31 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1A9nZe-0005v0-00 for mmusic@ietf.org; Wed, 15 Oct 2003 11:28:30 -0400 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] specifying the multicast interface Date: Wed, 15 Oct 2003 11:27:25 -0400 Message-ID: Thread-Topic: [MMUSIC] specifying the multicast interface Thread-Index: AcORspcV6gL69gKtTWC/qT4F7EAR3wBfdTnw From: "Matthew Heaney" To: "Thomas Zeng" , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Thomas Zeng [mailto:zeng@PacketVideo.COM]=20 > Sent: Monday, October 13, 2003 1:50 PM >=20 > Yes, you can provide the IP of the selected IF via the c=3D=20 > line in SDP,=20 But doesn't that specify the multicast address? The interface address is different -- it's the IP of the NIC used to multicast the session. > but the final say is upto RTSP negotiations,=20 > ie., you can use the Transport header in the SETUP=20 > request/response to over-ride SDP. Transport header has the=20 > following general parameters, quoting 2326: >=20 >=20 > destination: > The address to which a stream will be sent. The client may > specify the multicast address with the destination=20 > parameter. But isn't this the multicast address? This is not the same as the interface address. >=20 > source: > If the source address for the stream is different=20 > than can be > derived from the RTSP endpoint address (the server=20 > in playback > or the client in recording), the source MAY be specified. Not sure whether this qualifies as the interface address. > Hope this is the answer you are looking for. I don't think so, but thanks anyway. -Matt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 15 20:56:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01489 for ; Wed, 15 Oct 2003 20:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wQv-0002Wg-KY for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 20:56:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G0u5YT009709 for mmusic-archive@odin.ietf.org; Wed, 15 Oct 2003 20:56:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wQv-0002WW-FK for mmusic-web-archive@optimus.ietf.org; Wed, 15 Oct 2003 20:56: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 UAA01483 for ; Wed, 15 Oct 2003 20:55:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wQs-00062p-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 20:56:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A9wQs-00062l-00 for mmusic-web-archive@ietf.org; Wed, 15 Oct 2003 20:56:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wQr-0002W3-MO; Wed, 15 Oct 2003 20:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A9wQb-0002VW-Uy for mmusic@optimus.ietf.org; Wed, 15 Oct 2003 20:55: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 UAA01478 for ; Wed, 15 Oct 2003 20:55:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A9wQZ-00062i-00 for mmusic@ietf.org; Wed, 15 Oct 2003 20:55:43 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1A9wQY-00062Z-00 for mmusic@ietf.org; Wed, 15 Oct 2003 20:55:43 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9G0t9Pa004052; Wed, 15 Oct 2003 17:55:09 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id <40TFMXT0>; Wed, 15 Oct 2003 17:55:09 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17B8C@misty.packetvideo.com> From: Thomas Zeng To: "'Matthew Heaney'" , mmusic@ietf.org Subject: RE: [MMUSIC] specifying the multicast interface Date: Wed, 15 Oct 2003 17:55:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , Why does one need to publish "the IP of the NIC used to multicast the session" ? -----Original Message----- From: Matthew Heaney [mailto:mheaney@on2.com] Sent: Wednesday, October 15, 2003 8:27 AM To: Thomas Zeng; mmusic@ietf.org Subject: RE: [MMUSIC] specifying the multicast interface > -----Original Message----- > From: Thomas Zeng [mailto:zeng@PacketVideo.COM] > Sent: Monday, October 13, 2003 1:50 PM > > Yes, you can provide the IP of the selected IF via the c= > line in SDP, But doesn't that specify the multicast address? The interface address is different -- it's the IP of the NIC used to multicast the session. > but the final say is upto RTSP negotiations, > ie., you can use the Transport header in the SETUP > request/response to over-ride SDP. Transport header has the > following general parameters, quoting 2326: > > > destination: > The address to which a stream will be sent. The client may > specify the multicast address with the destination > parameter. But isn't this the multicast address? This is not the same as the interface address. > > source: > If the source address for the stream is different > than can be > derived from the RTSP endpoint address (the server > in playback > or the client in recording), the source MAY be specified. Not sure whether this qualifies as the interface address. > Hope this is the answer you are looking for. I don't think so, but thanks anyway. -Matt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 16 19:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29654 for ; Thu, 16 Oct 2003 19:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHJo-0000Tg-RF for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 19:14:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9GNE8VL001837 for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 19:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHJo-0000TX-M2 for mmusic-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 19:14: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 TAA29634 for ; Thu, 16 Oct 2003 19:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAHJn-0003zG-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 19:14:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAHJm-0003zD-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 19:14:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHJg-0000Sw-UE; Thu, 16 Oct 2003 19:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAHJQ-0000Ro-O4 for mmusic@optimus.ietf.org; Thu, 16 Oct 2003 19:13: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 TAA29626 for ; Thu, 16 Oct 2003 19:13:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAHJP-0003ys-00 for mmusic@ietf.org; Thu, 16 Oct 2003 19:13:43 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AAHJN-0003yI-00 for mmusic@ietf.org; Thu, 16 Oct 2003 19:13:42 -0400 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] specifying the multicast interface Date: Thu, 16 Oct 2003 19:13:09 -0400 Message-ID: Thread-Topic: [MMUSIC] specifying the multicast interface Thread-Index: AcOTgEzeFiq4n8vdSYu8Dno4r8zrHQAuZu+A From: "Matthew Heaney" To: "Thomas Zeng" , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Because a customer asked us to. A multicast session is started on a TrueCast server using a web-based admin interface. The admin user specifies the multicast address and port he wants, the name of the presentation, etc. =20 Currently, our admin tool doesn't allow you to specify the IP of the interface card, even though explicitly specifying the interface over which to multicast the session is allowed per the BSD socket API. So we have to fix it. For now I'll just use a GET_PARAMETER to get the interface list, and then augment the SETUP request with an "X-multicast-interface" header. > -----Original Message----- > From: Thomas Zeng [mailto:zeng@PacketVideo.COM]=20 > Sent: Wednesday, October 15, 2003 8:55 PM > To: Matthew Heaney; mmusic@ietf.org > Subject: RE: [MMUSIC] specifying the multicast interface >=20 >=20 > Why does one need to publish "the IP of the NIC used to=20 > multicast the session" ? >=20 > -----Original Message----- > From: Matthew Heaney [mailto:mheaney@on2.com] > Sent: Wednesday, October 15, 2003 8:27 AM > To: Thomas Zeng; mmusic@ietf.org > Subject: RE: [MMUSIC] specifying the multicast interface >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Thomas Zeng [mailto:zeng@PacketVideo.COM] > > Sent: Monday, October 13, 2003 1:50 PM > >=20 > > Yes, you can provide the IP of the selected IF via the c=3D > > line in SDP,=20 >=20 > But doesn't that specify the multicast address? The=20 > interface address is different -- it's the IP of the NIC used=20 > to multicast the session. >=20 >=20 >=20 > > but the final say is upto RTSP negotiations, > > ie., you can use the Transport header in the SETUP=20 > > request/response to over-ride SDP. Transport header has the=20 > > following general parameters, quoting 2326: > >=20 > >=20 > > destination: > > The address to which a stream will be sent. The client may > > specify the multicast address with the destination > > parameter. >=20 > But isn't this the multicast address? This is not the same=20 > as the interface address. >=20 >=20 > >=20 > > source: > > If the source address for the stream is different > > than can be > > derived from the RTSP endpoint address (the server=20 > > in playback > > or the client in recording), the source MAY be specified. >=20 > Not sure whether this qualifies as the interface address. >=20 >=20 > > Hope this is the answer you are looking for. >=20 > I don't think so, but thanks anyway. >=20 > -Matt >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 16 21:18:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02251 for ; Thu, 16 Oct 2003 21:18:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJFl-0005q6-Dh for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 21:18:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H1I5aT022440 for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 21:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJFl-0005pr-5e for mmusic-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 21:18: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 VAA02247 for ; Thu, 16 Oct 2003 21:17:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJFi-0004tw-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 21:18:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAJFi-0004ts-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 21:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJFh-0005p6-Ma; Thu, 16 Oct 2003 21:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJEz-0005oF-Pf for mmusic@optimus.ietf.org; Thu, 16 Oct 2003 21:17: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 VAA02229; Thu, 16 Oct 2003 21:17:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJEw-0004tT-00; Thu, 16 Oct 2003 21:17:14 -0400 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AAJEv-0004tD-00; Thu, 16 Oct 2003 21:17:13 -0400 Received: from dynamicsoft.com (dyn-tx-app-004.dfw.dynamicsoft.com [63.110.3.2]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9H1Geca001145; Thu, 16 Oct 2003 21:16:41 -0400 (EDT) Message-ID: <3F8F42F2.6030402@dynamicsoft.com> Date: Thu, 16 Oct 2003 21:16:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete Cordell CC: "Peterson, Jon" , Mmusic , midcom@ietf.org Subject: Re: [MMUSIC] Status of TURN References: <003301c3931a$781e72c0$0200000a@tkw> In-Reply-To: <003301c3931a$781e72c0$0200000a@tkw> 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 Just because its an individual submission does not mean that comments and criticisms are not welcome. Please feel free to send me a note. Thanks, Jonathan R. Pete Cordell wrote: > Dear Jon, > > I'm very surprised to see that TURN is being encouraged to be put forward as > an individual submission. We believe that TURN has major security flaws, is > incomplete, and there are better ways of achieving Symmetric NAT traversal. > Suggesting it should become an RFC without debate and full consideration > would be wrong. > > If you remember, TURN was just one of the candidates put forward as a > pre-Midcom solution that at that time was put aside in favour of developing > a consensus protocol. Despite our commitment, consensus wasn't reached, > mainly due to the amount of effort that was being put into SIP (RFC3261) by > other important stake holders. > > We feel that to arbitrarily promote TURN at this time is short cutting the > consensus making process. Surely, if there is sufficient interest in a > standard of this nature, the correct way forward is to assign it as a work > item in a suitable group and re-start the consensus process. If so, we > remain willing to help with time, resource and considerable technical > know-how. Several significant developments have meant the world of Symmetric > NAT traversal has advanced considerably since the pre-Midcom days. > > Regards, > > Pete. > > ============================================= > Pete Cordell > Ridgeway > ============================================= > > ----- Original Message ----- > From: "Peterson, Jon" > To: "'Joel Tran'" ; "Jonathan Rosenberg" > ; "Mmusic" > Sent: 09 October 2003 17:08 > Subject: RE: [MMUSIC] Status of TURN > > > >>The Transport Area Directors understand that this document will proceed as >>an individual submission, outside the context of any of the working groups >>in the Transport Area. It is clearly of interest to a number of these >>working groups. >> >>I gather that at least one more revision needs to be undertaken before > > this > >>document will be considered for publication as an RFC, but we're very >>interested to see it go forward. >> >>Jon Peterson >>NeuStar, Inc. >>(co-AD for Transport) >> >> >>>-----Original Message----- >>>From: Joel Tran [mailto:joel_tran@hotmail.com] >>>Sent: Tuesday, October 07, 2003 11:08 AM >>>To: Jonathan Rosenberg; Mmusic >>>Subject: [MMUSIC] Status of TURN >>> >>> >>>Hi Jonathan, >>> >>>I would like to ask you two little questions concerning TURN. >>> >>>First, I would like to know what is the exact status of TURN? >>>Will it be >>>adopted as a Workgroup item of MMUSIC since TURN is refeered >>>in various >>>documents? >>> >>>Second, I would like to ask you if there is a reason why the >>>lastest version >>>of the draft is not on the IETF web and only available throught >>>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? >>> >>>Thanks, >>>...J >>> >>>_______________________________________________ >>>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 > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 16 21:20:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02318 for ; Thu, 16 Oct 2003 21:20:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJHi-00060O-KB for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 21:20:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9H1K6XG023078 for mmusic-archive@odin.ietf.org; Thu, 16 Oct 2003 21:20:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJHg-000609-TC for mmusic-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 21:20: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 VAA02306 for ; Thu, 16 Oct 2003 21:19:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJHe-0004uj-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 21:20:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAJHd-0004ug-00 for mmusic-web-archive@ietf.org; Thu, 16 Oct 2003 21:20:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJHf-0005yr-80; Thu, 16 Oct 2003 21:20:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAJHV-0005xt-Ep for mmusic@optimus.ietf.org; Thu, 16 Oct 2003 21:19: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 VAA02299 for ; Thu, 16 Oct 2003 21:19:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAJHS-0004uR-00 for mmusic@ietf.org; Thu, 16 Oct 2003 21:19:50 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AAJHR-0004u6-00 for mmusic@ietf.org; Thu, 16 Oct 2003 21:19:50 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9H1JBPa038400; Thu, 16 Oct 2003 18:19:11 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id <40TFNB9M>; Thu, 16 Oct 2003 18:19:11 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17B94@misty.packetvideo.com> From: Thomas Zeng To: "'Matthew Heaney'" , Thomas Zeng , mmusic@ietf.org Subject: RE: [MMUSIC] specifying the multicast interface Date: Thu, 16 Oct 2003 18:19:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , Interesting... So if we add a new parameter (since we are revising RFC2326, it is not impossible to as for an optional parameter, say, "multicast-interface") to the Transport header in SETUP request/response, you no longer has to use the "x-multicast-interface" parameter which is not interoperable? But you may want to convince people that others might be interested in this new parameter ... Just a thought. thomas > -----Original Message----- > From: Matthew Heaney [mailto:mheaney@on2.com] > Sent: Thursday, October 16, 2003 4:13 PM > To: Thomas Zeng; mmusic@ietf.org > Subject: RE: [MMUSIC] specifying the multicast interface > > > Because a customer asked us to. > > A multicast session is started on a TrueCast server using a web-based > admin interface. The admin user specifies the multicast address and > port he wants, the name of the presentation, etc. > > Currently, our admin tool doesn't allow you to specify the IP of the > interface card, even though explicitly specifying the interface over > which to multicast the session is allowed per the BSD socket > API. So we > have to fix it. > > For now I'll just use a GET_PARAMETER to get the interface list, and > then augment the SETUP request with an "X-multicast-interface" header. > > > > > -----Original Message----- > > From: Thomas Zeng [mailto:zeng@PacketVideo.COM] > > Sent: Wednesday, October 15, 2003 8:55 PM > > To: Matthew Heaney; mmusic@ietf.org > > Subject: RE: [MMUSIC] specifying the multicast interface > > > > > > Why does one need to publish "the IP of the NIC used to > > multicast the session" ? > > > > -----Original Message----- > > From: Matthew Heaney [mailto:mheaney@on2.com] > > Sent: Wednesday, October 15, 2003 8:27 AM > > To: Thomas Zeng; mmusic@ietf.org > > Subject: RE: [MMUSIC] specifying the multicast interface > > > > > > > > > > > -----Original Message----- > > > From: Thomas Zeng [mailto:zeng@PacketVideo.COM] > > > Sent: Monday, October 13, 2003 1:50 PM > > > > > > Yes, you can provide the IP of the selected IF via the c= > > > line in SDP, > > > > But doesn't that specify the multicast address? The > > interface address is different -- it's the IP of the NIC used > > to multicast the session. > > > > > > > > > but the final say is upto RTSP negotiations, > > > ie., you can use the Transport header in the SETUP > > > request/response to over-ride SDP. Transport header has the > > > following general parameters, quoting 2326: > > > > > > > > > destination: > > > The address to which a stream will be sent. The > client may > > > specify the multicast address with the destination > > > parameter. > > > > But isn't this the multicast address? This is not the same > > as the interface address. > > > > > > > > > > source: > > > If the source address for the stream is different > > > than can be > > > derived from the RTSP endpoint address (the server > > > in playback > > > or the client in recording), the source MAY be > specified. > > > > Not sure whether this qualifies as the interface address. > > > > > > > Hope this is the answer you are looking for. > > > > I don't think so, but thanks anyway. > > > > -Matt > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 17 10:14:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03847 for ; Fri, 17 Oct 2003 10:14:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVNB-0007MB-6J for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 10:14:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HEEXwe028275 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 10:14:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVNB-0007Ly-35 for mmusic-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 10:14: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 KAA03764 for ; Fri, 17 Oct 2003 10:14:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVN8-0003nm-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 10:14:30 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAVN8-0003nj-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 10:14:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVMf-0007HZ-6v; Fri, 17 Oct 2003 10:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAVM7-0007Gj-V6 for mmusic@optimus.ietf.org; Fri, 17 Oct 2003 10:13: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 KAA03637 for ; Fri, 17 Oct 2003 10:13:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAVM5-0003mM-00 for mmusic@ietf.org; Fri, 17 Oct 2003 10:13:25 -0400 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AAVM5-0003mJ-00 for mmusic@ietf.org; Fri, 17 Oct 2003 10:13:25 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9HEDNI2017788; Fri, 17 Oct 2003 16:13:23 +0200 (MEST) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45JY4SCR; Fri, 17 Oct 2003 16:17:03 +0200 Message-ID: <3F8FF902.6090807@ericsson.com> Date: Fri, 17 Oct 2003 16:13:22 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Heaney CC: Thomas Zeng , mmusic@ietf.org Subject: Re: [MMUSIC] specifying the multicast interface References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Matthew, I have some problem of understanding why you need to specify the outgoing interface to use. Is this multihomes servers that you have an interest of ensuring that the transmissions are made using the right sender address? A little more explanation on the needs and advantages to specify the sending interface would be appreciated. Especially if we should consider adding anything to the RTSP standard. Then I would also recommend you to skip the "X-" from your parameter name, as if it would be standardized in the future you don't have to change the implementations, to also support the new name. The only consideration is that if someone in the future registers this name is that the proprietary use are responsible for updating there feature or giving it a new name. cheers Magnus Matthew Heaney wrote: > Because a customer asked us to. > > A multicast session is started on a TrueCast server using a web-based > admin interface. The admin user specifies the multicast address and > port he wants, the name of the presentation, etc. > > Currently, our admin tool doesn't allow you to specify the IP of the > interface card, even though explicitly specifying the interface over > which to multicast the session is allowed per the BSD socket API. So we > have to fix it. > > For now I'll just use a GET_PARAMETER to get the interface list, and > then augment the SETUP request with an "X-multicast-interface" header. > > > > >>-----Original Message----- >>From: Thomas Zeng [mailto:zeng@PacketVideo.COM] >>Sent: Wednesday, October 15, 2003 8:55 PM >>To: Matthew Heaney; mmusic@ietf.org >>Subject: RE: [MMUSIC] specifying the multicast interface >> >> >>Why does one need to publish "the IP of the NIC used to >>multicast the session" ? >> >>-----Original Message----- >>From: Matthew Heaney [mailto:mheaney@on2.com] >>Sent: Wednesday, October 15, 2003 8:27 AM >>To: Thomas Zeng; mmusic@ietf.org >>Subject: RE: [MMUSIC] specifying the multicast interface >> >> >> >> >> >>>-----Original Message----- >>>From: Thomas Zeng [mailto:zeng@PacketVideo.COM] >>>Sent: Monday, October 13, 2003 1:50 PM >>> >>>Yes, you can provide the IP of the selected IF via the c= >>>line in SDP, >> >>But doesn't that specify the multicast address? The >>interface address is different -- it's the IP of the NIC used >>to multicast the session. >> >> >> >> >>>but the final say is upto RTSP negotiations, >>>ie., you can use the Transport header in the SETUP >>>request/response to over-ride SDP. Transport header has the >>>following general parameters, quoting 2326: >>> >>> >>> destination: >>> The address to which a stream will be sent. The client may >>> specify the multicast address with the destination >>>parameter. >> >>But isn't this the multicast address? This is not the same >>as the interface address. >> >> >> >>> source: >>> If the source address for the stream is different >>>than can be >>> derived from the RTSP endpoint address (the server >>>in playback >>> or the client in recording), the source MAY be specified. >> >>Not sure whether this qualifies as the interface address. >> >> >> >>>Hope this is the answer you are looking for. >> >>I don't think so, but thanks anyway. >> >>-Matt >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 17 12:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09791 for ; Fri, 17 Oct 2003 12:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXjs-00069x-2Y for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 12:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HGk8TC023674 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 12:46:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXjr-00069l-Us for mmusic-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 12:46: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 MAA09788 for ; Fri, 17 Oct 2003 12:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXjq-0005TC-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 12:46:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAXjp-0005T9-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 12:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXjk-00068u-WA; Fri, 17 Oct 2003 12:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXjX-00068b-Ra for mmusic@optimus.ietf.org; Fri, 17 Oct 2003 12:45: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 MAA09768 for ; Fri, 17 Oct 2003 12:45:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXjW-0005T6-00 for mmusic@ietf.org; Fri, 17 Oct 2003 12:45:46 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AAXjV-0005T2-00 for mmusic@ietf.org; Fri, 17 Oct 2003 12:45:45 -0400 Received: Received on2.com Subject: RE: [MMUSIC] specifying the multicast interface Date: Fri, 17 Oct 2003 12:41:27 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [MMUSIC] specifying the multicast interface content-class: urn:content-classes:message Thread-Index: AcOUuPOTbNGmRkUjSeKASlpynVg4qAADuFcw X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 From: "Matthew Heaney" To: "Magnus Westerlund" Cc: "Thomas Zeng" , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Friday, October 17, 2003 10:13 AM >=20 > I have some problem of understanding why you need to specify the=20 > outgoing interface to use. Is this multihomes servers that=20 > you have an=20 > interest of ensuring that the transmissions are made using the right=20 > sender address? A little more explanation on the needs and=20 > advantages to=20 > specify the sending interface would be appreciated. Especially if we=20 > should consider adding anything to the RTSP standard. I don't know the exact reasons why our customer asked for the feature, but we do have machines here with two interface cards. In our case each card is on a completely different network. =20 Suppose a client on one network is interested in joining the multicast session. If the server does not specify the local interface from which to send, then do we have any guarantee that the datagrams will reach the client? (I still have to run this test.) =20 Suppose the "default" interface (the one chosen by the kernel if we don't explicitly specify) is the one attached to the other network. Does this mean that the client (who isn't on the network to which the "default" interface is attached) doesn't ever see any of those packets? It just seems odd that RTSP allows you to specify the TTL (IP_MULTICAST_TTL), but provides no way to specify the local interface for sending (IP_MULTICAST_IF) or whether local loopback occurs (IP_MULTICAST_LOOP). > Then I would also recommend you to skip the "X-" from your parameter=20 > name, as if it would be standardized in the future you don't have to=20 > change the implementations, to also support the new name. The only=20 > consideration is that if someone in the future registers this name is=20 > that the proprietary use are responsible for updating there=20 > feature or=20 > giving it a new name. Server mods are easy enough for me. I just realized, though, that it might be nice to allow the admin user to specify either the IP of the interface or its name. Maybe I need to two headers? Here are some ideas: interface local-interface multicast-interface interface-address interface-name multicast-interface-address multicast-interface-name etc -Matt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 17 13:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10458 for ; Fri, 17 Oct 2003 13:02:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXzJ-0006qq-OK for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 13:02:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HH25ha026330 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 13:02:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXzJ-0006qb-HY for mmusic-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 13:02: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 NAA10446 for ; Fri, 17 Oct 2003 13:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXzH-0005eu-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 13:02:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAXzH-0005er-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 13:02:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXzF-0006q8-O7; Fri, 17 Oct 2003 13:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAXyN-0006ph-EW for mmusic@optimus.ietf.org; Fri, 17 Oct 2003 13:01: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 NAA10432 for ; Fri, 17 Oct 2003 13:00:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAXyL-0005ek-00 for mmusic@ietf.org; Fri, 17 Oct 2003 13:01:05 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AAXyK-0005ee-00 for mmusic@ietf.org; Fri, 17 Oct 2003 13:01:04 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AAXy8-0000Qc-00; Fri, 17 Oct 2003 10:00:52 -0700 Date: Fri, 17 Oct 2003 10:00:52 -0700 From: Tom Marshall To: Matthew Heaney Cc: Magnus Westerlund , Thomas Zeng , mmusic@ietf.org Subject: Re: [MMUSIC] specifying the multicast interface Message-ID: <20031017170052.GA1557@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Suppose the "default" interface (the one chosen by the kernel if we > don't explicitly specify) is the one attached to the other network. > Does this mean that the client (who isn't on the network to which the > "default" interface is attached) doesn't ever see any of those packets? >=20 > It just seems odd that RTSP allows you to specify the TTL > (IP_MULTICAST_TTL), but provides no way to specify the local interface > for sending (IP_MULTICAST_IF) or whether local loopback occurs > (IP_MULTICAST_LOOP). I'm not really familiar with your application, but our server is written to always use the same interface for the transport and control connections.=20 This should solve the problem of the "default" interface. Do you or your customer have other reasons for wanting to specify the interface? --=20 Beware of Programmers who carry screwdrivers. -- Leonard Brandwein --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/kCBEqznSmcYu2m8RAmRIAJ994OKXonQF1CmZ3NbOPZyBzNthTQCeOYMN IIFCcHUX/k/0umx1RvyE24A= =S3Gq -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 17 16:11:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21887 for ; Fri, 17 Oct 2003 16:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAawG-0008L8-42 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 16:11:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HKB8ka032052 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 16:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAawF-0008Kt-UH for mmusic-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:11: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 QAA21796 for ; Fri, 17 Oct 2003 16:10:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAawE-0000gO-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 16:11:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAawD-0000gL-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 16:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAawA-0008KB-8H; Fri, 17 Oct 2003 16:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAavP-0008In-Sw for mmusic@optimus.ietf.org; Fri, 17 Oct 2003 16:10: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 QAA21694 for ; Fri, 17 Oct 2003 16:10:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAavO-0000e9-00 for mmusic@ietf.org; Fri, 17 Oct 2003 16:10:14 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AAavM-0000dp-00 for mmusic@ietf.org; Fri, 17 Oct 2003 16:10:13 -0400 Received: Received on2.com content-class: urn:content-classes:message Subject: RE: [MMUSIC] specifying the multicast interface MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Oct 2003 16:08:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: Thread-Topic: [MMUSIC] specifying the multicast interface Thread-Index: AcOU0FmuOV5SW9ZLRCShO2VH4VZRMQAGSCgQ From: "Matthew Heaney" To: "Tom Marshall" Cc: "Magnus Westerlund" , "Thomas Zeng" , , "Frank Galligan" , "Tom Finegan" X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tom Marshall [mailto:tmarshall@real.com]=20 > Sent: Friday, October 17, 2003 1:01 PM >=20 > I'm not really familiar with your application, but our server=20 > is written to always use the same interface for the transport=20 > and control connections.=20 > This should solve the problem of the "default" interface. =20 The server sends RTP packets out over one interface (the "default" interface). The client is on a network attached to another interface. If the client doesn't get any RTP packets, then I still have a problem. > Do=20 > you or your customer have other reasons for wanting to=20 > specify the interface? I assume my customer has his reasons for asking, but he didn't specify why. I can try to get more info. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 17 16:28:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22825 for ; Fri, 17 Oct 2003 16:28:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAbCc-0000gg-UK for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 16:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HKS2xM002636 for mmusic-archive@odin.ietf.org; Fri, 17 Oct 2003 16:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAbCc-0000gR-Qc for mmusic-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:28: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 QAA22805 for ; Fri, 17 Oct 2003 16:27:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAbCa-00011B-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 16:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAbCa-000118-00 for mmusic-web-archive@ietf.org; Fri, 17 Oct 2003 16:28:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAbCb-0000fy-Mw; Fri, 17 Oct 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAbBx-0000ek-Sx for mmusic@optimus.ietf.org; Fri, 17 Oct 2003 16:27: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 QAA22713 for ; Fri, 17 Oct 2003 16:27:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAbBv-0000zo-00 for mmusic@ietf.org; Fri, 17 Oct 2003 16:27:20 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AAbBv-0000zj-00 for mmusic@ietf.org; Fri, 17 Oct 2003 16:27:19 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AAbBs-0000fm-00; Fri, 17 Oct 2003 13:27:16 -0700 Date: Fri, 17 Oct 2003 13:27:16 -0700 From: Tom Marshall To: Matthew Heaney Cc: Magnus Westerlund , Thomas Zeng , mmusic@ietf.org, Frank Galligan , Tom Finegan Subject: Re: [MMUSIC] specifying the multicast interface Message-ID: <20031017202716.GD1926@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="//IivP0gvsAy3Can" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --//IivP0gvsAy3Can Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 17, 2003 at 04:08:03PM -0400, Matthew Heaney wrote: >=20 >=20 > > -----Original Message----- > > From: Tom Marshall [mailto:tmarshall@real.com]=20 > > Sent: Friday, October 17, 2003 1:01 PM > >=20 > > I'm not really familiar with your application, but our server=20 > > is written to always use the same interface for the transport=20 > > and control connections.=20 > > This should solve the problem of the "default" interface. =20 >=20 > The server sends RTP packets out over one interface (the "default" > interface). The client is on a network attached to another interface. > If the client doesn't get any RTP packets, then I still have a problem. Yes, and the implication was that if the server sent RTP packets out on the same interface that has the control connection instead of the "default" interface, it may solve the problem. I"m interested to see if it does. --=20 Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun --//IivP0gvsAy3Can Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/kFCkqznSmcYu2m8RAh0uAJ49J97uuyNwL4BhJYFo/o6t5m+KyACfe5qV h/IN/GhwIiYEncnRJ6BIas4= =FwTX -----END PGP SIGNATURE----- --//IivP0gvsAy3Can-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Oct 18 15:54:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07943 for ; Sat, 18 Oct 2003 15:54:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAx9J-0007ui-9S for mmusic-archive@odin.ietf.org; Sat, 18 Oct 2003 15:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IJs53M030414 for mmusic-archive@odin.ietf.org; Sat, 18 Oct 2003 15:54:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAx9J-0007uK-4y for mmusic-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 15:54: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 PAA07937 for ; Sat, 18 Oct 2003 15:53:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAx9H-0005fM-00 for mmusic-web-archive@ietf.org; Sat, 18 Oct 2003 15:54:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAx9H-0005fI-00 for mmusic-web-archive@ietf.org; Sat, 18 Oct 2003 15:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAx9F-0007tW-6B; Sat, 18 Oct 2003 15:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAx8Y-0007qJ-3b for mmusic@optimus.ietf.org; Sat, 18 Oct 2003 15:53: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 PAA07931 for ; Sat, 18 Oct 2003 15:53:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAx8W-0005ec-00 for mmusic@ietf.org; Sat, 18 Oct 2003 15:53:16 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 1AAx8V-0005dv-00 for mmusic@ietf.org; Sat, 18 Oct 2003 15:53:16 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HMY001E2XVSLU@smtp2.vsnl.net> for mmusic@ietf.org; Sun, 19 Oct 2003 01:22:44 +0530 (IST) Received: from ([219.65.46.40]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Sun, 19 Oct 2003 01:22:44 +0530 (IST) Date: Sun, 19 Oct 2003 01:22:19 +0530 From: Deepak Kotian To: IETF MMUSIC WG Reply-to: Deepak Kotian Message-id: <001201c395b1$571eeb60$282e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3F8BA87C.6030100@ericsson.com> Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] The initial audio lags video by around 17-20 seconds and after that it is OK on RealOne via RTSP/RTP 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 a problem, The initial audio lags video by around 17-20 seconds and after that it is OK on RealOne via RTSP/RTP. Basically the audio comes after 17-20 seconds against video. i.e. the initial audio packets are not played at all. The audio packets are sent at all time. We have implemented RFC 2250 for MPEG1 Video and Audio and RTSP minimal server. Any suggestion on this one please. Thanks and Regards Deepak _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Oct 18 15:55:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07981 for ; Sat, 18 Oct 2003 15:55:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxAG-00083B-AG for mmusic-archive@odin.ietf.org; Sat, 18 Oct 2003 15:55:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9IJt42w030939 for mmusic-archive@odin.ietf.org; Sat, 18 Oct 2003 15:55:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxAG-00082w-5Q for mmusic-web-archive@optimus.ietf.org; Sat, 18 Oct 2003 15:55: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 PAA07967 for ; Sat, 18 Oct 2003 15:54:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAxAE-0005gQ-00 for mmusic-web-archive@ietf.org; Sat, 18 Oct 2003 15:55:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAxAE-0005gN-00 for mmusic-web-archive@ietf.org; Sat, 18 Oct 2003 15:55:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAxAF-00081x-5w; Sat, 18 Oct 2003 15:55:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAx9T-0007vW-CM for mmusic@optimus.ietf.org; Sat, 18 Oct 2003 15:54: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 PAA07941 for ; Sat, 18 Oct 2003 15:54:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAx9R-0005fb-00 for mmusic@ietf.org; Sat, 18 Oct 2003 15:54:13 -0400 Received: from smtp2.vsnl.net ([203.200.235.232]) by ietf-mx with esmtp (Exim 4.12) id 1AAx9R-0005f2-00 for mmusic@ietf.org; Sat, 18 Oct 2003 15:54:13 -0400 Received: from happy ([127.0.0.1]) by smtp2.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HMY001K0XXHLU@smtp2.vsnl.net> for mmusic@ietf.org; Sun, 19 Oct 2003 01:23:43 +0530 (IST) Received: from ([219.65.46.40]) by smtp2.vsnl.net (InterScan E-Mail VirusWall Unix); Sun, 19 Oct 2003 01:23:43 +0530 (IST) Date: Sun, 19 Oct 2003 01:23:19 +0530 From: Deepak Kotian To: IETF MMUSIC WG Reply-to: Deepak Kotian Message-id: <001901c395b1$7b2247a0$282e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] Re: The initial audio lags video by around 17-20 seconds and after that it is OK on RealOne via RTSP/RTP 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 Forgot to add, The player is realOne. Thanks and Regards Deepak ----- Original Message ----- From: "Deepak Kotian" To: "IETF MMUSIC WG" Sent: Sunday, October 19, 2003 1:22 AM Subject: The initial audio lags video by around 17-20 seconds and after that it is OK on RealOne via RTSP/RTP > Hi, > > I have a problem, > The initial audio lags video by around 17-20 seconds and after that it is OK > on RealOne via RTSP/RTP. > Basically the audio comes after 17-20 seconds against video. > i.e. the initial audio packets are not played at all. The audio packets > are sent at all time. > We have implemented RFC 2250 for MPEG1 Video and Audio > and RTSP minimal server. > > Any suggestion on this one please. > > Thanks and Regards > Deepak > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 01:39:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01058 for ; Mon, 20 Oct 2003 01:39:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSkx-0000SY-Au for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 01:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9K5d3wK001760 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 01:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSkx-0000SJ-6Q for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 01:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01037 for ; Mon, 20 Oct 2003 01:38:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABSkt-0004DY-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 01:38:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABSkt-0004DU-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 01:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSku-0000Q2-Ca; Mon, 20 Oct 2003 01:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABSka-0000I7-EH for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 01:38: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 BAA01026 for ; Mon, 20 Oct 2003 01:38:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABSkX-0004DG-00 for mmusic@ietf.org; Mon, 20 Oct 2003 01:38:37 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1ABSkW-0004D6-00 for mmusic@ietf.org; Mon, 20 Oct 2003 01:38:36 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9K5brPb038455; Sun, 19 Oct 2003 22:37:54 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id <40TFN07B>; Sun, 19 Oct 2003 22:37:53 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BB3@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , IETF MMUSIC WG Subject: RE: [MMUSIC] RTSP: Bug 649272 - Default way of deriving aggregate URL Date: Sun, 19 Oct 2003 22:37:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: It might help to show an example where the aggregate control URI is not in SDP, yet the client conjures up one which the server then accepts. Thanks, - thomas > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 14, 2003 11:06 AM > To: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP: Bug 649272 - Default way of > deriving aggregate URL > > > Hi, > > Please provide comments by Wednesday the 22th of October, or > this text > will be part of the next draft version. > > Cheers > > Magnus > > Magnus Westerlund wrote: > > > Hi, > > > > This is the proposed text in regards bug: > > > > http://rtsp.org/bug640272 - Default way of deriving aggregate URL > > > > The text is from the SETUP method description: > > > > "The server {\MUST} generate a session identifier in response to a > > successful {\SETUP} request, unless a {\SETUP} request to a server > > includes a session identifier, in which case the server {\MUST} > > bundle this setup request into the existing session (aggregated > > session) or return error 459 (Aggregate Operation Not Allowed) > > (see Section ~\ref{sec:error459}). An Aggregate control URI > > {\MUST} be used to control an aggregated session. This URI {\MUST} > > be different from the stream control URIs of the individual media > > streams included in the aggregate. The Aggregate control URI > > {\SHOULD} be specified by the session description since there is > > no general rule for deriving it from the various stream control > > URIs in the session. > > > > If an Aggregate control URI is not specified in the session > > description, it is probably a indication that non-aggregated > > control should be used. However a client {\MAY} try to SETUP the > > session in aggregated control. If the server refuse to aggregate > > the specified media, the server {\SHALL} use the 459 error code. > > If the server allows the aggregation, then the client {\MUST} > > create an URI for aggregate control of the session. This URI > > {\MUST} contain the servers host address and {\MUST} contain the > > port, if applicable (e.g. not default port). Once an URI is used > > to refer to an aggregation for a given session, that URI {\MUST} > > be used to refer to that aggregation for the duration of the > > session." > > > > > > Please comment > > > > > > Cheers > > > > Magnus Westerlund > > > > Multimedia Technologies, Ericsson Research EAB/TVA/A > > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 8 4048287 > > Torshamsgatan 23 | Fax +46 8 7575550 > > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 10:02:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26596 for ; Mon, 20 Oct 2003 10:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabi-0003N7-JP for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 10:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KE22Eb012961 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 10:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabi-0003My-Ec for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 10:02: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 KAA26584 for ; Mon, 20 Oct 2003 10:01:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABabg-0000Uz-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 10:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABabf-0000Uw-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 10:01:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabg-0003MK-VJ; Mon, 20 Oct 2003 10:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABabM-0003HL-4m for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 10:01: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 KAA26581; Mon, 20 Oct 2003 10:01:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABabK-0000Us-00; Mon, 20 Oct 2003 10:01:38 -0400 Received: from zinc.btinternet.com ([194.73.73.148]) by ietf-mx with esmtp (Exim 4.12) id 1ABabJ-0000Up-00; Mon, 20 Oct 2003 10:01:37 -0400 Received: from host213-122-136-104.in-addr.btopenworld.com ([213.122.136.104] helo=tkw) by zinc.btinternet.com with smtp (Exim 3.22 #23) id 1ABaaS-0004Wo-00; Mon, 20 Oct 2003 15:00:44 +0100 Message-ID: <001c01c39712$c4427100$0200000a@tkw> From: "Pete Cordell" To: "Jonathan Rosenberg" Cc: "Peterson, Jon" , "Mmusic" , References: <003301c3931a$781e72c0$0200000a@tkw> <3F8F42F2.6030402@dynamicsoft.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 15:01:05 +0100 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, That's generous of you, but I basically feel that there is either a need for this work, in which case it should be done as part of the normal open IETF process, or there isn't a need, in which case it should go no further. As I've said elsewhere, I think the reason the effort failed last time was because people were working on the SIP RFC. I know you're superhuman (I am impressed by your output), but I think even you were saturated at that time. And I actually agree with your prioritisation at the time (there's no point in having a traversal solution if there is nothing that needs traversing!) However, to put it bluntly, I would feel aggrieved if those circumstances were later used to justify fast tracking a proposal that did not represent consensus of the interested parties involved. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Jonathan Rosenberg" To: "Pete Cordell" Cc: "Peterson, Jon" ; "Mmusic" ; Sent: 17 October 2003 02:16 Subject: [midcom] Re: [MMUSIC] Status of TURN > Just because its an individual submission does not mean that comments > and criticisms are not welcome. Please feel free to send me a note. > > Thanks, > Jonathan R. > > Pete Cordell wrote: > > > Dear Jon, > > > > I'm very surprised to see that TURN is being encouraged to be put forward as > > an individual submission. We believe that TURN has major security flaws, is > > incomplete, and there are better ways of achieving Symmetric NAT traversal. > > Suggesting it should become an RFC without debate and full consideration > > would be wrong. > > > > If you remember, TURN was just one of the candidates put forward as a > > pre-Midcom solution that at that time was put aside in favour of developing > > a consensus protocol. Despite our commitment, consensus wasn't reached, > > mainly due to the amount of effort that was being put into SIP (RFC3261) by > > other important stake holders. > > > > We feel that to arbitrarily promote TURN at this time is short cutting the > > consensus making process. Surely, if there is sufficient interest in a > > standard of this nature, the correct way forward is to assign it as a work > > item in a suitable group and re-start the consensus process. If so, we > > remain willing to help with time, resource and considerable technical > > know-how. Several significant developments have meant the world of Symmetric > > NAT traversal has advanced considerably since the pre-Midcom days. > > > > Regards, > > > > Pete. > > > > ============================================= > > Pete Cordell > > Ridgeway > > ============================================= > > > > ----- Original Message ----- > > From: "Peterson, Jon" > > To: "'Joel Tran'" ; "Jonathan Rosenberg" > > ; "Mmusic" > > Sent: 09 October 2003 17:08 > > Subject: RE: [MMUSIC] Status of TURN > > > > > > > >>The Transport Area Directors understand that this document will proceed as > >>an individual submission, outside the context of any of the working groups > >>in the Transport Area. It is clearly of interest to a number of these > >>working groups. > >> > >>I gather that at least one more revision needs to be undertaken before > > > > this > > > >>document will be considered for publication as an RFC, but we're very > >>interested to see it go forward. > >> > >>Jon Peterson > >>NeuStar, Inc. > >>(co-AD for Transport) > >> > >> > >>>-----Original Message----- > >>>From: Joel Tran [mailto:joel_tran@hotmail.com] > >>>Sent: Tuesday, October 07, 2003 11:08 AM > >>>To: Jonathan Rosenberg; Mmusic > >>>Subject: [MMUSIC] Status of TURN > >>> > >>> > >>>Hi Jonathan, > >>> > >>>I would like to ask you two little questions concerning TURN. > >>> > >>>First, I would like to know what is the exact status of TURN? > >>>Will it be > >>>adopted as a Workgroup item of MMUSIC since TURN is refeered > >>>in various > >>>documents? > >>> > >>>Second, I would like to ask you if there is a reason why the > >>>lastest version > >>>of the draft is not on the IETF web and only available throught > >>>http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt? > >>> > >>>Thanks, > >>>...J > >>> > >>>_______________________________________________ > >>>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 > > > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 11:47:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01308 for ; Mon, 20 Oct 2003 11:47:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcFO-0004GK-H0 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 11:47:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KFl6vW016375 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 11:47:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcFO-0004G2-Br for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 11: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 LAA01301 for ; Mon, 20 Oct 2003 11:46:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcFN-0001Zc-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 11:47:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABcFM-0001ZZ-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 11:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcFK-0004DN-1P; Mon, 20 Oct 2003 11:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcEP-0003zv-Au for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 11:46: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 LAA01274; Mon, 20 Oct 2003 11:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcEO-0001ZN-00; Mon, 20 Oct 2003 11:46:04 -0400 Received: from protactinium.btinternet.com ([194.73.73.176]) by ietf-mx with esmtp (Exim 4.12) id 1ABcEN-0001ZK-00; Mon, 20 Oct 2003 11:46:03 -0400 Received: from dial81-135-11-42.in-addr.btopenworld.com ([81.135.11.42] helo=tkw) by protactinium.btinternet.com with smtp (Exim 3.22 #23) id 1ABcE6-0000bu-00; Mon, 20 Oct 2003 16:45:47 +0100 Message-ID: <003a01c39721$709a9640$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: <86BB4302-0309-11D8-A84F-000A95E35274@cisco.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 16:47:12 +0100 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 Melinda, I would argue that individual submissions are part of the IETF process, but are not necessarily open. If we and Jonathan were to evolve TURN (or something similar) outside of a working group item, that would effectively be a behind closed doors effort, and would not be open in the sense that most IETF working group work is. Publishing TURN as an individual submission would also set a bad precedent. There's been a significant boom in the number of traversal solution providers lately. Publishing TURN would set the precedent that it is OK to bypass the open process (at least in the traversal space) and use the individual submission process to get that attractive RFC number (marketing people and buyers don't really care what type it is). True, the individual process requires a lot of patience. However, the open process requires a thick skin, a willingness to compromise, re-writing code, possibly delayed launch dates and ... a lot of patience! Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 15:27 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > On Monday, October 20, 2003, at 10:01 AM, Pete Cordell wrote: > > That's generous of you, but I basically feel that there is either a > > need for > > this work, in which case it should be done as part of the normal open > > IETF > > process, or there isn't a need, in which case it should go no further. > > I hope it's understood that the publication of individual > submissions (i.e. not working group output) is in fact part of > the normal open IETF process, available to anybody who wishes > to jump through the various hoops to do it. RFC 2026 mentions > it but probably doesn't make it as clear as it should. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 12:15:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02291 for ; Mon, 20 Oct 2003 12:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcgU-0003Bl-5L for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 12:15:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KGF6vI012251 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 12:15:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcgU-0003BW-1O for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 12:15: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 MAA02268 for ; Mon, 20 Oct 2003 12:14:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcgS-0001tv-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 12:15:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABcgS-0001ts-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 12:15:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcgS-0003AO-Fl; Mon, 20 Oct 2003 12:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcg1-00034X-Px for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 12:14: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 MAA02241; Mon, 20 Oct 2003 12:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcg0-0001t3-00; Mon, 20 Oct 2003 12:14:36 -0400 Received: from smtp3.vsnl.net ([203.200.235.233]) by ietf-mx with esmtp (Exim 4.12) id 1ABcfz-0001sp-00; Mon, 20 Oct 2003 12:14:36 -0400 Received: from happy ([172.16.28.233]) by smtp3.vsnl.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HN200AK7D2Y2D@smtp3.vsnl.net>; Mon, 20 Oct 2003 21:43:50 +0530 (IST) Received: from ([219.65.46.127]) by smtp3.vsnl.net (InterScan E-Mail VirusWall Unix); Mon, 20 Oct 2003 21:43:50 +0530 (IST) Date: Mon, 20 Oct 2003 21:42:42 +0530 From: Deepak Kotian To: avt@ietf.org, IETF MMUSIC WG Reply-to: Deepak Kotian Message-id: <001601c39724$fe228d80$7f2e41db@vsnl.net> Organization: pcs MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: multipart/alternative; boundary="Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)" X-Priority: 3 X-MSMail-priority: Normal Subject: [MMUSIC] Re: ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a sendto 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. --Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Also an additional information. F001:0:0:0:0:0:0:43 MULTICast address works fine with sendto, but FF12::224.5.6.7 does not work. Also, the errno is 99 , the errno menitioned in the earlier mail was not OK. Any inputs from anyone on this now. Thanks and Regards Deepak ----- Original Message ----- From: Deepak Kotian To: avt@ietf.org Sent: Sunday, October 19, 2003 5:15 PM Subject: ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a sendto Hi, We are currently facing a problem when we try mutlicast IP FF12::224.5.6.7 on Linux. The function inet_pton() returns > 0, that means the IP is OK, but when we do a sendto(), it gives an error, EADDRINVAL. The kernel used is 2.4.18-3 and ipv6 is enable. Can one please let me know, how to make this multicast IPV6 sendto() functionality work properly. I think, this is not the right forum, but if some has worked on it, can one please share his experience on it. Or does anyone know the right forum for this query. Thanks and Regards Deepak --Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
 
Also an additional information.
F001:0:0:0:0:0:0:43 MULTICast address works
fine with sendto, but FF12::224.5.6.7 does not
work.
Also, the errno is 99 , the errno menitioned in the
earlier mail was not OK.
 
Any inputs from anyone on this now.
 
Thanks and Regards
Deepak
 
----- Original Message -----
Sent: Sunday, October 19, 2003 5:15 PM
Subject: ipv6 multicast problem on Linux kernel 2.4.18-3 while doing a sendto

Hi,   
 
We  are currently facing a problem when
we try mutlicast IP FF12::224.5.6.7 on Linux.
The function inet_pton() returns > 0, that means the IP is OK, but
when we do a sendto(), it gives an error, EADDRINVAL.
 
The kernel used is 2.4.18-3 and ipv6 is enable.
Can one please let me know, how to make this multicast IPV6
sendto() functionality work properly.
 
I think, this is not the right forum, but if some has worked on it,
can one please share his experience on it.
Or does anyone know the right forum for this query.
 
         
Thanks and Regards
Deepak
 
--Boundary_(ID_FKut3SW8i0b9+1uwDNuT9Q)-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 13:13:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04174 for ; Mon, 20 Oct 2003 13:13:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdac-0007Zy-4U for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 13:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KHD6Yh029128 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 13:13:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdac-0007Zj-0s for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 13:13: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 NAA04149 for ; Mon, 20 Oct 2003 13:12:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdaa-0002Od-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 13:13:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABdaZ-0002Oa-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 13:13:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdaY-0007Yb-W6; Mon, 20 Oct 2003 13:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABdZY-0007GY-GG for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 13:12: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 NAA04083; Mon, 20 Oct 2003 13:11:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABdZW-0002Np-00; Mon, 20 Oct 2003 13:11:58 -0400 Received: from carbon.btinternet.com ([194.73.73.92]) by ietf-mx with esmtp (Exim 4.12) id 1ABdZW-0002Nm-00; Mon, 20 Oct 2003 13:11:58 -0400 Received: from host213-122-128-105.in-addr.btopenworld.com ([213.122.128.105] helo=tkw) by carbon.btinternet.com with smtp (Exim 3.22 #23) id 1ABdZB-0002Q6-00; Mon, 20 Oct 2003 18:11:37 +0100 Message-ID: <000b01c3972d$6e4a6e40$0200000a@tkw> From: "Pete Cordell" To: "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: <07AB2C20-0318-11D8-A84F-000A95E35274@cisco.com> Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 18:13:02 +0100 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 agree that the process allows this. However, I believe it would be unwise to take this route. The IESG can recommend that a draft not be published if (among other reasons) it conflicts with work in the IETF. The effort was stopped because people were too busy doing other things, rather than it was not possible to reach consensus, hence it is not a failed effort in that sense. Now that people have more time, it seems that there is still interest in it from more than one group. Hence the correct thing to do is see whether the work should be resumed. (If you like, the work should have been considered paused rather than stopped.) It seems an act of considerable bad faith to stop a piece of work going forward because you are busy, and then later claim that your individual submission should be adopted because the work was stopped. There seems only two options: the work item is re-started, or all work is stopped. To do otherwise would be an abuse of the spirit of the IETF even if it is not in violation of the written rules. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Melinda Shore" To: "Pete Cordell" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 17:11 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN > On Monday, October 20, 2003, at 11:47 AM, Pete Cordell wrote: > > I would argue that individual submissions are part of the IETF > > process, but > > are not necessarily open. If we and Jonathan were to evolve TURN (or > > something similar) outside of a working group item, that would > > effectively > > be a behind closed doors effort, and would not be open in the sense > > that > > most IETF working group work is. > > That's one way to look at it, I suppose, but the point really > is that publication of individual submissions is a route open > to anybody and that there's no process subversion here. Note > as well that it's being published in draft form and he's > solicited input. > > I'm actually not very happy about this, myself, and would > oppose pretty much any relaying technology. Aside from the > technical issues, among the unfortunate consequences of all > this pre-midcom stuff has been that it's taken the pressure > off of firewall/NAT vendors to do something useful. That's > not good. But regardless of how I feel personally about all > this stuff I really think that advancing an individual draft > towards publication is not even remotely an abuse of IETF > process. > > Melinda > > > _______________________________________________ > midcom mailing list > midcom@ietf.org > https://www1.ietf.org/mailman/listinfo/midcom _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 20 18:51:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12479 for ; Mon, 20 Oct 2003 18:51:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABirh-0000AW-2U for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 18:51:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9KMp50g000642 for mmusic-archive@odin.ietf.org; Mon, 20 Oct 2003 18:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABirg-0000AH-RR for mmusic-web-archive@optimus.ietf.org; Mon, 20 Oct 2003 18:51: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 SAA12460 for ; Mon, 20 Oct 2003 18:50:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABird-0002rI-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 18:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABird-0002rF-00 for mmusic-web-archive@ietf.org; Mon, 20 Oct 2003 18:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABird-00008G-QD; Mon, 20 Oct 2003 18:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABirB-0008Qm-FU for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 18:50: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 SAA12435 for ; Mon, 20 Oct 2003 18:50:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABir8-0002qh-00 for mmusic@ietf.org; Mon, 20 Oct 2003 18:50:30 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ABir7-0002qe-00 for mmusic@ietf.org; Mon, 20 Oct 2003 18:50:29 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9KMoM4t028986 for ; Mon, 20 Oct 2003 15:50:23 -0700 (PDT) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9KMoHU1002935 for ; Mon, 20 Oct 2003 15:50:20 -0700 (PDT) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 20 Oct 2003 15:50:17 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Date: Mon, 20 Oct 2003 15:50:15 -0700 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F33D1A9@NAEX01.na.qualcomm.com> Thread-Topic: Status of draft-ietf-mmusic-sdescriptions-01.txt Thread-Index: AcOXXIghqbE5B6qCRtGhfJNnoVr7vg== From: "Barany, Pete" To: X-OriginalArrivalTime: 20 Oct 2003 22:50:17.0679 (UTC) FILETIME=[885875F0:01C3975C] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Status of draft-ietf-mmusic-sdescriptions-01.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: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Could someone please tell me what is the status of the following I-D? Thanks in advance. Regards, Pete _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 05:38:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11318 for ; Tue, 21 Oct 2003 05:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxu-0006lQ-Fn for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L9c9MY025963 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxs-0006kQ-HU for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 05:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11288 for ; Tue, 21 Oct 2003 05:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABsxm-0001Xm-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABsxl-0001Xd-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxl-0006gf-G8; Tue, 21 Oct 2003 05:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABb13-0001H7-4C for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 10:28: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 KAA28378; Mon, 20 Oct 2003 10:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABb10-0000j2-00; Mon, 20 Oct 2003 10:28:10 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ABb0z-0000gO-00; Mon, 20 Oct 2003 10:28:09 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 16:25:40 +0200 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KERTiw028439; Mon, 20 Oct 2003 07:27:29 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANH70641; Mon, 20 Oct 2003 07:27:27 -0700 (PDT) Date: Mon, 20 Oct 2003 10:27:25 -0400 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , To: "Pete Cordell" From: Melinda Shore In-Reply-To: <001c01c39712$c4427100$0200000a@tkw> Message-Id: <86BB4302-0309-11D8-A84F-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, October 20, 2003, at 10:01 AM, Pete Cordell wrote: > That's generous of you, but I basically feel that there is either a > need for > this work, in which case it should be done as part of the normal open > IETF > process, or there isn't a need, in which case it should go no further. I hope it's understood that the publication of individual submissions (i.e. not working group output) is in fact part of the normal open IETF process, available to anybody who wishes to jump through the various hoops to do it. RFC 2026 mentions it but probably doesn't make it as clear as it should. Melinda _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 06:28:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11321 for ; Tue, 21 Oct 2003 05:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxu-0006lL-Dt for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L9c9Au025965 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxs-0006kP-Gj for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 05:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11291 for ; Tue, 21 Oct 2003 05:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABsxm-0001Xr-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABsxm-0001Xf-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxn-0006hJ-LE; Tue, 21 Oct 2003 05:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABfgu-0004Fn-Jb for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 15:27: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 PAA16831; Mon, 20 Oct 2003 15:27:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABfgt-0004iV-00; Mon, 20 Oct 2003 15:27:43 -0400 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ABfgs-0004gL-00; Mon, 20 Oct 2003 15:27:42 -0400 Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 20 Oct 2003 12:27:11 -0700 Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Oct 2003 12:27:11 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 12:27:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 20 Oct 2003 12:26:42 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 20 Oct 2003 12:27:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7097.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [midcom] Re: [MMUSIC] Status of TURN Date: Mon, 20 Oct 2003 12:27:06 -0700 Message-ID: Thread-Topic: [midcom] Re: [MMUSIC] Status of TURN thread-index: AcOXLYb7Mf07MWqPSTKNyEE9RIqPAAAEcP7g From: "Christian Huitema" To: "Pete Cordell" , "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , X-OriginalArrivalTime: 20 Oct 2003 19:27:10.0367 (UTC) FILETIME=[28243AF0:01C39740] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Individual submissions are a well established part of the process, and should be considered a fine way to make progress when a working group would not. There is a catch, however. Individual contributions are very seldom published as proposed standards -- they normally end up as either experimental or informational. The criteria for publishing something as informational ought to be, demonstration of at least some significant interest in the community -- but not necessarily demonstration of consensus. The bar for refusing publication in the presence of enough interest has to be somewhat high -- basically, the group has to be convinced that implementing the proposal as is would damage the Internet.=20 Obviously, publication as a proposed standard would require the equivalent of WG consensus. I don't believe there is such consensus on TURN. -- Christian Huitema _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 06:28:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11320 for ; Tue, 21 Oct 2003 05:38:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxu-0006lM-El for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9L9c9Xk025964 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 05:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxs-0006kO-GJ for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 05:38:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11294 for ; Tue, 21 Oct 2003 05:37:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABsxm-0001Xs-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ABsxl-0001Xe-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 05:38:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABsxm-0006gt-JF; Tue, 21 Oct 2003 05:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ABcdV-0002bJ-65 for mmusic@optimus.ietf.org; Mon, 20 Oct 2003 12:12: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 MAA02166; Mon, 20 Oct 2003 12:11:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ABcdT-0001qq-00; Mon, 20 Oct 2003 12:11:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.74.5]) by ietf-mx with esmtp (Exim 4.12) id 1ABcdT-0001ql-00; Mon, 20 Oct 2003 12:11:59 -0400 Received: from cisco.com (171.71.177.254) by ams-iport-1.cisco.com with ESMTP; 20 Oct 2003 18:09:31 +0200 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h9KGBJiw001237; Mon, 20 Oct 2003 09:11:19 -0700 (PDT) Received: from cisco.com (stealth-10-32-241-42.cisco.com [10.32.241.42]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id ANH79877; Mon, 20 Oct 2003 09:11:17 -0700 (PDT) Date: Mon, 20 Oct 2003 12:11:15 -0400 Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , To: "Pete Cordell" From: Melinda Shore In-Reply-To: <003a01c39721$709a9640$0200000a@tkw> Message-Id: <07AB2C20-0318-11D8-A84F-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Monday, October 20, 2003, at 11:47 AM, Pete Cordell wrote: > I would argue that individual submissions are part of the IETF > process, but > are not necessarily open. If we and Jonathan were to evolve TURN (or > something similar) outside of a working group item, that would > effectively > be a behind closed doors effort, and would not be open in the sense > that > most IETF working group work is. That's one way to look at it, I suppose, but the point really is that publication of individual submissions is a route open to anybody and that there's no process subversion here. Note as well that it's being published in draft form and he's solicited input. I'm actually not very happy about this, myself, and would oppose pretty much any relaying technology. Aside from the technical issues, among the unfortunate consequences of all this pre-midcom stuff has been that it's taken the pressure off of firewall/NAT vendors to do something useful. That's not good. But regardless of how I feel personally about all this stuff I really think that advancing an individual draft towards publication is not even remotely an abuse of IETF process. Melinda _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 13:35:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27413 for ; Tue, 21 Oct 2003 13:35:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PR-00033Q-17 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LHZ5wd011736 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PQ-00033D-Sj for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 13:35: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 NAA27392 for ; Tue, 21 Oct 2003 13:34:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0PO-0006Pw-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0PO-0006Pt-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PO-00031P-9L; Tue, 21 Oct 2003 13:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0Ok-0002ox-5q for mmusic@optimus.ietf.org; Tue, 21 Oct 2003 13:34: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 NAA27370 for ; Tue, 21 Oct 2003 13:34:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0Oh-0006P4-00 for mmusic@ietf.org; Tue, 21 Oct 2003 13:34:19 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AC0Oh-0006ON-00 for mmusic@ietf.org; Tue, 21 Oct 2003 13:34:19 -0400 Received: from cisco.com (sjc-vpn3-796.cisco.com [10.21.67.28]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h9LHXkQY028074; Tue, 21 Oct 2003 10:33:47 -0700 (PDT) Message-ID: <3F956DF8.6AF49A35@cisco.com> Date: Tue, 21 Oct 2003 13:33:44 -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: "Barany, Pete" CC: mmusic@ietf.org Subject: Re: [MMUSIC] Status of draft-ietf-mmusic-sdescriptions-01.txt References: <17D8F6DF3ED94D40BD607380866D9B7F33D1A9@NAEX01.na.qualcomm.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 There will be an -02 version before the end of this week. -- Flemming "Barany, Pete" wrote: > Hi, > > Could someone please tell me what is the status of the following I-D? > > > > Thanks in advance. > > Regards, > > Pete > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 16:38:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06722 for ; Tue, 21 Oct 2003 16:38:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3GV-0002Gi-Hy for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 16:38:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LKc2sm008700 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 16:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3GU-0002GF-B0 for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 16:38: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 QAA06610 for ; Tue, 21 Oct 2003 16:37:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC3GS-0001EX-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 16:38:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC3GR-0001EU-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 16:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3GT-0002FW-6f; Tue, 21 Oct 2003 16:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC3G2-00021u-77 for mmusic@optimus.ietf.org; Tue, 21 Oct 2003 16:37:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06556; Tue, 21 Oct 2003 16:37:22 -0400 (EDT) Message-Id: <200310212037.QAA06556@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, 21 Oct 2003 16:37:22 -0400 Subject: [MMUSIC] I-D ACTION:draft-andreasen-mmusic-securityprecondition-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. Title : Security Preconditions for Session Description Protocol Media Streams Author(s) : F. Andreasen, et. al. Filename : draft-andreasen-mmusic-securityprecondition-00.txt Pages : 8 Date : 2003-10-20 This document defines a new security precondition for the Session Description Protocol precondition framework described in RFC 3312. A security precondition can be used to delay session establishment or modification until media stream security has been negotiated successfully. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-securityprecondition-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-andreasen-mmusic-securityprecondition-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-andreasen-mmusic-securityprecondition-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-10-21163947.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-andreasen-mmusic-securityprecondition-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-andreasen-mmusic-securityprecondition-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-21163947.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 19:00:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16583 for ; Tue, 21 Oct 2003 19:00:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5Ty-0000Qi-6i for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:00:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LN06Hf001646 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:00:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5Tx-0000Px-3Z for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:00: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 SAA16521 for ; Tue, 21 Oct 2003 18:59:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5Tt-00044o-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:00:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC5Tt-00044l-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:00:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5Tt-0000OR-Nu; Tue, 21 Oct 2003 19:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5TO-0008Rt-2R for mmusic@optimus.ietf.org; Tue, 21 Oct 2003 18:59: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 SAA16485 for ; Tue, 21 Oct 2003 18:59:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5TK-00044L-00 for mmusic@ietf.org; Tue, 21 Oct 2003 18:59:26 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AC5TK-00043Q-00 for mmusic@ietf.org; Tue, 21 Oct 2003 18:59:26 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60619 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AC5Sq-0005cT-00 for mmusic@ietf.org; Tue, 21 Oct 2003 23:58:56 +0100 Date: Tue, 21 Oct 2003 23:58:52 +0100 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Colin Perkins To: mmusic@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <23F62818-041A-11D8-B566-000A957FC5F2@csperkins.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDP: Use of multiple c= lines in an m= block 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 off-list discussion with Magnus and Gonzalo, is was asked if it is allowed to have multiple c= lines in a m= block, but not at session level, since RFC 2327 is not entirely clear. The following clarification was proposed for the end of Section 5.7 of draft-ietf-mmusic-sdp-new-14: OLD: Multiple addresses or "c=" lines MAY be specified on a per-media basis. They MUST NOT be specified for a session-level "c=" field. NEW: Multiple addresses or "c=" lines MAY be specified on a per-media basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. They MUST NOT be specified for a session-level "c=" field. Any comments? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 19:07:21 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17189 for ; Tue, 21 Oct 2003 19:07:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5ah-0001xO-VL for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:07:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LN73UO007514 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:07:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5ah-0001wz-Gv for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:07:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17161 for ; Tue, 21 Oct 2003 19:06:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5ae-0004H8-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:07:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC5ad-0004H5-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5ag-0001v7-6c; Tue, 21 Oct 2003 19:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5Zt-0001kQ-GA for mmusic@optimus.ietf.org; Tue, 21 Oct 2003 19:06: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 TAA17118 for ; Tue, 21 Oct 2003 19:06:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5Zq-0004G3-00 for mmusic@ietf.org; Tue, 21 Oct 2003 19:06:10 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AC5Zp-0004FD-00 for mmusic@ietf.org; Tue, 21 Oct 2003 19:06:09 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60623 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AC5ZL-0005dg-00; Wed, 22 Oct 2003 00:05:39 +0100 Date: Wed, 22 Oct 2003 00:05:37 +0100 Subject: Re: [MMUSIC] SDP b= clarification Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: mmusic@ietf.org To: Tom Marshall From: Colin Perkins In-Reply-To: <20030902215852.GD1475@real.com> Message-Id: <1567E9F1-041B-11D8-B566-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, Sep 2, 2003, at 22:58 Europe/London, Tom Marshall wrote: > On Tue, Sep 02, 2003 at 09:58:17PM +0100, Colin Perkins wrote: >> On Thursday, Aug 28, 2003, at 20:38 Europe/London, Tom Marshall wrote: >>> In RFC3556, the example SDP shows multiple b=lines in the media >>> sections. >>> In RFC2327 (and the updated draft sdp-new-13), the b= line is >>> specified >>> without any corresponding note that the line may be repeated. I've >>> always >>> assumed this meant exactly one instance was allowed. If that is the >>> case, >>> the example SDP in 3556 is noncompliant. Since multiple b= lines are >>> presumedly desirable, I think the sdp-new draft should be updated to >>> reflect >>> this. >> >> The ABNF in draft-ietf-mmusic-sdp-new-13.txt explicitly allows >> repetition. >> >> bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) >> bwtype = token >> bandwidth = 1*DIGIT > > Cool. Could we get a note in the text that corresponds with the ABNF? Provided there are no objections, if you suggest explicit wording changes, I can incorporate them into -15. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 21 19:14:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17871 for ; Tue, 21 Oct 2003 19:14:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5hS-0003aT-FY for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LNE2NY013751 for mmusic-archive@odin.ietf.org; Tue, 21 Oct 2003 19:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5hS-0003Zi-6a for mmusic-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 19:14:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17836 for ; Tue, 21 Oct 2003 19:13:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5hQ-0004Tz-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:14:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC5hQ-0004Tw-00 for mmusic-web-archive@ietf.org; Tue, 21 Oct 2003 19:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5hQ-0003Yj-PJ; Tue, 21 Oct 2003 19:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC5gQ-0003J7-Br for mmusic@optimus.ietf.org; Tue, 21 Oct 2003 19:12:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17775 for ; Tue, 21 Oct 2003 19:12:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC5gO-0004SN-00 for mmusic@ietf.org; Tue, 21 Oct 2003 19:12:56 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AC5gM-0004RG-00 for mmusic@ietf.org; Tue, 21 Oct 2003 19:12:55 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9LNCEPa099923; Tue, 21 Oct 2003 16:12:14 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id <40TF3T5S>; Tue, 21 Oct 2003 16:12:14 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BD1@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" Cc: IETF MMUSIC WG Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Date: Tue, 21 Oct 2003 16:12:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: During one of the telecon for RTSP, I recall that a decision was made to deprecate "time=" parameter in Range header. We have found a use case in the context of playlist support, where we would like to use "time=" parameter in Range header in the PLAY request as designed in RFC2326, quoted below: 10.5 PLAY ... The Range header may also contain a time parameter. This parameter specifies a time in UTC at which the playback should start. If the message is received after the specified time, playback is started immediately. The time parameter may be used to aid in synchronization of streams obtained from different sources. In light of this, would it be possible to retain this "time parameter"? thanks, thomas -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Tuesday, October 14, 2003 9:53 PM To: Thomas Zeng Cc: 'Magnus Westerlund'; IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Yes, SIP BYE is used to terminate the call, which also results in the termination of the media sessions. -Jonathan R. Thomas Zeng wrote: > On item g: > > - Look into SIP to see how they have resolved the discrepancies > between media and signaling channel. > > Could someone fammiliar with SIP help me out here: I need to know what > method of SIP to look, is it SIP BYE method by any chance? > > (I saw that SIP has a BYE method to terminate the call in the signalling > channel. ) > > thanks, > thomas > > > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, October 14, 2003 11:04 AM > To: IETF MMUSIC WG > Subject: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 > > > Hi, > > Here is the preliminary minutes for todays telecon. Please comment. > > RTSP Telecon the 14th of October > > Participants: > Magnus Westerlund, Colin Perkins, Aravind Narasimhan, and Tom Marshall. > > Agenda: > > 1. Opening of meeting. > > 2. Administrative > - Scribe > - IETF in Minneapolis > * Off-line Meeting? > * What to present. > > 3. Since last meeting (1st of October). > a. http://rtsp.org/bug507882 - RTP timestamp and pause > - Aravind to write up text > > b. http://rtsp.org/bug742328 - How to handle PLAY request when at the > end of a media clip > - Text sent to mailing list, please review. > > c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. > - Needs text > > d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL > - Text sent to the mailing list > > e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media > - Text sent to the mailing list. > > f. http://rtsp.org/bug531189 - How does REDIRECT method work > - Needs somebody to write up. > > g. http://rtsp.org/bug810678 - How to indicate end of media stream > - Strawman proposal available from Thomas. For discussion. > > h. http://rtsp.org/bug770522 - Request to response time is not limited. > - Some discussion on mailing list. Sean to write up text. > > i. http://rtsp.org/bug810681 - The updated specification version number > - Awaiting investigation results regarding changes by Aravind. > > j. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state > - Posted to the mailing list, no comments. Unless comments are > received it will be edited in. > > k. http://rtsp.org/bug804219 - How to handle sync in re-SETUP > - Text posted to the list. No comments received so far. > > l. http://rtsp.org/bug806404 - Re-SETUP of transport parameters > - Awaiting proposal text from Geetha. > > m. http://rtsp.org/bug810666 - Removal of SETUP in play state > - Proposed to be removed. Message sent to the list. > > 4. New Issues > > a. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address > classes > > b. http://rtsp.org/bug795314 - Caching of OPTIONS request > > 5. Any other business > > 6. Next Telecon: Proposal Wednesday, 3rd of December. > > 7. End of meeting > > Minutes > ------- > > 1. Meeting was opened. > > 2. - Magnus volunteered to write the minutes. > > - IETF meeting in Minneapolis: > * Colin will request a conference room for a out-side of normal > agenda meeting. A guess of on the number of participants are > around 15. > > * The authors will perform a status update on the specification in > the WG session. The current resolutions and open issues will be > presented. > > 3. > > a. Nothing has happened. > > b. Await review from the WG. > > c. Status not changed. > > d. Await review from the WG. > > e. Was not sent yet, but will be available directly after meeting. > Review comments needed. > > f. The remaining issue is with implicit closing of the session. The > previous meeting has agreement on the functionality but some minor > issues around use of "connection" needs resolving. Best way of > resolving this is probably to present a specification text proposal. > Aravind will take this as a second priority issue. > > g. Send comments on the document to list. The discussion resolved that > this can be divided into several pieces: > > - We need to document in the RTSP specification regarding RTP what > happens when a source times out a SSRC or receives a RTCP BYE for a > source. > > - Using BYE is not suitable way to indicate the end of the stream. > The motivation for this can be seen in Thomas proposal. > > - Look into SIP to see how they have resolved the discrepancies > between media and signaling channel. > > h. Awaits text from Sean. > > i. This is a later decision when we have received a list of changes that > are accurate. > > j. Unless comments are received by Monday the 20th of October, this > resolution will be edited in. Magnus will post a reply to the initial > mail pointing out the deadline. > > k. Will be kept in the text unless comments are review by Wednesday the > 22th of October. > > l. Awaits text. > > m. Will be edited in unless comments are received by Monday the 20th of > October. > > 4. > a. Question raised is: Are there need for a server to announce through > SDP or other pre SETUP mechanism which address classes it supports to > the client? > > There was discussion on this topic and the resolution was the > following: > > It should be assumed that a server being possible to find in DNS with > a certain address class will support both signaling and media > delivery for that address. Thus a RTSP request over TCP/IPv6 will > send media using that source IPv6 address. > > b. The OPTIONS request has some dependency on server state and what > content that are addressed. Therefore it seems doubtful that caching of > OPTIONS request are possible. In general it seems that the only > really cachable RTSP request/response pair is for DESCRIBE. > > 5. No other business. > > 6. Preliminary date is the 3rd of December, which is three weeks after > the IETF meeting. > > 7. Meeting was closed. > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 01:16:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27970 for ; Wed, 22 Oct 2003 01:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLn-0006xh-4v for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 01:16:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M5G3uX026755 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 01:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLn-0006xS-0u for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 01:16:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27961 for ; Wed, 22 Oct 2003 01:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACBLj-0000At-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 01:15:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACBLj-0000Aq-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 01:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLk-0006vX-R2; Wed, 22 Oct 2003 01:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBLg-0006um-1J for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 01:15: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 BAA27958; Wed, 22 Oct 2003 01:15:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACBLc-0000An-00; Wed, 22 Oct 2003 01:15:52 -0400 Received: from rhenium.btinternet.com ([194.73.73.93]) by ietf-mx with esmtp (Exim 4.12) id 1ACBLb-0000Aj-00; Wed, 22 Oct 2003 01:15:52 -0400 Received: from host213-122-34-206.in-addr.btopenworld.com ([213.122.34.206] helo=tkw) by rhenium.btinternet.com with smtp (Exim 3.22 #23) id 1ACBL7-000235-00; Wed, 22 Oct 2003 06:15:22 +0100 Message-ID: <004d01c3985b$b1f25340$0200000a@tkw> From: "Pete Cordell" To: "Christian Huitema" , "Melinda Shore" Cc: "Jonathan Rosenberg" , "Peterson, Jon" , "Mmusic" , References: Subject: Re: [midcom] Re: [MMUSIC] Status of TURN Date: Wed, 22 Oct 2003 06:14:03 +0100 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.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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 What you say Christian is technically absolutely correct. However this communities appetite for implementing and labelling their products with even -00 draft material suggests to me that many implementers (and probably their customers) are not bothered by these subtleties of IETF process. Certainly it would help to know whether informational or proposed standard is being sought for this draft. Pete. ============================================= Pete Cordell +44 1473 635863 ============================================= ----- Original Message ----- From: "Christian Huitema" To: "Pete Cordell" ; "Melinda Shore" Cc: "Jonathan Rosenberg" ; "Peterson, Jon" ; "Mmusic" ; Sent: 20 October 2003 20:27 Subject: RE: [midcom] Re: [MMUSIC] Status of TURN Individual submissions are a well established part of the process, and should be considered a fine way to make progress when a working group would not. There is a catch, however. Individual contributions are very seldom published as proposed standards -- they normally end up as either experimental or informational. The criteria for publishing something as informational ought to be, demonstration of at least some significant interest in the community -- but not necessarily demonstration of consensus. The bar for refusing publication in the presence of enough interest has to be somewhat high -- basically, the group has to be convinced that implementing the proposal as is would damage the Internet. Obviously, publication as a proposed standard would require the equivalent of WG consensus. I don't believe there is such consensus on TURN. -- Christian Huitema _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 01:27:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28165 for ; Wed, 22 Oct 2003 01:27:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBWP-0002K7-Sk for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 01:27:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M5R176008925 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBWP-0002Js-O9 for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 01:27: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 BAA28159 for ; Wed, 22 Oct 2003 01:26:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACBWM-0000FE-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 01:26:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACBWM-0000FB-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 01:26:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBWO-0002It-M2; Wed, 22 Oct 2003 01:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACBVY-0001uA-JZ for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 01:26: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 BAA28139 for ; Wed, 22 Oct 2003 01:25:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACBVV-0000El-00 for mmusic@ietf.org; Wed, 22 Oct 2003 01:26:05 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1ACBVU-0000Ea-00 for mmusic@ietf.org; Wed, 22 Oct 2003 01:26:04 -0400 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9M5PZUP010608 for ; Tue, 21 Oct 2003 22:25:35 -0700 (PDT) Received: from jamba (jamba.Eng.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HN500B8H8EN7W@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 21 Oct 2003 22:25:35 -0700 (PDT) Date: Tue, 21 Oct 2003 22:25:53 -0700 From: Geetha Srikantan To: mmusic@ietf.org Message-id: <1066800352.27652.3.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP transport negotiation 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 Hello everyone, Here is the promised write-up on RTSP transport negotiation..sorry for the delay. If there is agreement on the content of this note, I can write up text for the RTSP draft. thanks geetha Topic: RTSP Transport negotiation using SETUP during play state. Introduction The RTSP specification allows for negotiation of transport parameters via the SETUP method, while the RTSP session is in play state. The transport parameters that can be negotiated and the exact form of this negotiation is under-specified in the RTSP documents. This note is an attempt to clarify some of the issues around transport negotiation for inclusion in the ongoing revision of RTSP. The recent interest in mobility for RTSP implementations also impacts transport parameters used by the session. For instance, a wireless RTSP client could be assigned a new IP address, or may experience change of network characteristics, while it is in the midst of a RTSP session. These issues are also addressed in this note. Outline: 1. Objective 2. Enumeration of all Transport Parameters 3. Transport Parameters Excluded from Negotiation 4. Negotiable Transport Parameters 5. Impact of Transport Negotiation 6. Examples 6.1 Client IP Address Changes 6.2 UDP -> TCP 6.3 TCP -> UDP 7. Other transport related changes to RTSP draft 8. Summary 1. Objective: The main goals of this document are to * Provide an enumeration of transport parameters. * Identify transport parameters that cannot be negotiated with minimal impact on other sessions. * Propose transport parameters that can be negotiated during play state. * Determine implications of changing these parameters via a SETUP request while the session is in play state. * Provide examples demonstrating transport negotiation. 2. Enumeration of all Transport Parameters The following is a list of all transport parameters in the current RTSP draft. unicast/multicast destination source mode (=PLAY) interleaved layers (for multicast) ttl (for multicast port (for multicast) client_port (for RTP) server_port (for RTP) ssrc (for RTP) url 3. Transport Parameters Excluded from Negotiation It is recommended that the following parameters be excluded from the negotiation process. mode url unicast/multicast layers ttl ssrc destination source As the "mode" parameter is restricted to a single value in the current draft, it can be excluded. As per the recent proposal to not support addition of urls via SETUP during play state, the "url" parameter can be excluded. Changing from multicast to unicast based on a single RTSP session's SETUP, would impact all the other clients accessing the multicast session. Several issues need to be considered in this case, including transport negotiation. Similarly, changing from unicast to multicast also has implications beyond a single RTSP session. Changes to other multicast-related parameters, "layers", "ssrc", "ttl" most likely requires specification beyond transport negotiation. The recommendation is to *not* specify changing the transport from "unicast" to "multicast" or vice versa, and also not specify changes to the "layers" and "ttl" parameters, in this draft. It is recommedned that negotiation of multicast-related transport parameters should be deferred to an RTSP-extension document. Once an RTSP session has been initiated and the "destination" and "source" have been established - i.e. a multicast "destination" has been identified, and the stream "source" has been identified, there should be no need to change these parameters. It is recommended that the "destination" and "source" parameters not be negotiated when the session is in play state. The case of the client IP address change is signaled in a different manner, outlined in the next section. 4. Negotiable Transport Parameters Hence there are three main conditions that require transport negotiation for unicast: * client IP address changes * client wants to switch transport from UDP -> TCP * client wants to switch transport from TCP -> UDP Changes in the client IP address can be indicated using a new "client_ip" parameter. Hence the parameters that are impacted by transport negotiation are: client_ip interleaved client_port server_port 5. Impact of Transport Negotiation The first column describes the primary change, the second and third columns describe any secondary transport parameters that MUST or MAY change as a result of the primary change. Changed MUST MAY ------- ---- --- Client IP address client_ip client_port server_port UDP -> TCP interleaved Server may change Drop client_port interleaved channel ids Drop server_port in response. TCP -> UDP client_port in request client_ip server_port in response client_port in response Drop interleaved 6. Examples 6.1 Client IP Address Changes C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 CSeq: 1 S->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 164 v=0 o=- 2890844256 2890842807 IN IP4 172.16.2.93 s=RTSP Session i=An Example of RTSP Session Usage a=control:rtsp://foo/twister t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://foo/twister/audio m=video 0 RTP/AVP 26 a=control:rtsp://foo/twister/video C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001 S->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001; server_port=9000-9001 Session: 12345678 C->S: SETUP rtsp://foo/twister/video RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003; server_port=9004-9005 Session: 12345678 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 4 Range: npt=0- Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=rtsp://foo/twister/video; seq=9810092;rtptime=3450012, url=rtsp://foo/twister/audio;seq=5923;rtptime=22234432 Range: npt=0-30.76 ... now change client IP address .... C->S: SETUP rtsp://foo/twister/video RTSP/1.0 CSeq: 5 Transport: RTP/AVP;unicast;client_ip=C: RTSP/1.0 200 OK CSeq: 5 Transport: RTP/AVP;unicast;client_ip=; client_port=8002-8003;server_port=9004-9005 RTP-Info: url=rtsp://foo/twister/video; seq=;rtptime=, Range: npt=5-30.76 Session: 12345678 C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 6 Transport:RTP/AVP;unicast;client_ip=; client_port=8000-8001;server_port=9000-9001 Range: npt=5- Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Transport: RTP/AVP;unicast;client_ip=; client_port=8000-8001;server_port=9000-9001 RTP-Info:url=rtsp://foo/twister/audio; seq=;rtptime= Range: npt=5-30.76 Session: 12345678 6.2 UDP -> TCP C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 CSeq: 1 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Content-Length: 230 Content-Type: application/sdp Cseq: 1 v=0 o=- 3262117360 3262117360 IN IP4 0.0.0.0 s=RTSP Session c=IN IP4 0.0.0.0 t=0 0 a=control:* a=range:npt=0-10.566000 m=video 0 RTP/AVP 26 a=control:rtsp://foo/twister/video m=audio 0 RTP/AVP 0 a=control:rtsp://foo/twister/audio C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 S->C: RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; server_port=9000-9001 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 3 Session: 12345678 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ CSeq: 3 RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 Range: npt=0- Session: 12345678 ... now request TCP ... C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 4 Transport: RTP/AVP/TCP;interleaved=0-1 S->C: RTSP/1.0 200 OK Cseq: 4 Transport: RTP/AVP/TCP;unicast; client_ip=;interleaved=0-1 RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= Range: npt=0-10.56600 Session: 12345678 6.3 TCP -> UDP C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 CSeq: 1 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Content-Length: 230 Content-Type: application/sdp Cseq: 1 v=0 o=- 3262117360 3262117360 IN IP4 0.0.0.0 s=RTSP Session c=IN IP4 0.0.0.0 t=0 0 a=control:* a=range:npt=0-10.566000 m=video 0 RTP/AVP 26 a=control:rtsp://foo/twister/video m=audio 0 RTP/AVP 0 a=control:rtsp://foo/twister/audio C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP/TCP;interleaved=0-1 S->C: RTSP/1.0 200 OK Cseq: 2 Session: 12345678 Transport: RTP/AVP/TCP;unicast;client_ip=;interleaved=0-1 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 3 Session: 12345678 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Cseq: 3 RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 Range: npt=0- Session: 12345678 ... now request UDP ... C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 4 Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 Range: npt=0- S->C: RTSP/1.0 200 OK CSeq: 4 Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; server_port=9000-9001 RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= Range: npt=0-10.56600 Session: 12345678 7. Other transport related changes to RTSP draft A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to transport parameters. (a) Section 13.40: Page 81: Are "src_addr" and "dest_addr" parameters going away? If these are relevant for NAT, perhaps they belong in the NAT document? Page 83-83: BNF indicates "client_port" and "server_port" will be indicated as 'port1-port2'. This doesn't seem adequate for the case where the RTP and RTCP ports are non-adjacent (per the new RTP spec rfc 3550). Proposal: client_port: rtp=, rtcp= server_port: rtp=, rtcp= (b) Appendix B, B.1.1 Page 115: Mentions "src_addresses" and "dest_addresses" - what are these? Page 116: "non-continuous" ports - might want to rephrase to "non-adjacent" (or "non-continguous") ports? 8. Summary This note recommends negotiation of a few transport parameters and specifies mechanisms to do so. One new transport parameter "client_ip" is recommended for use in cases where the client's IP address changes during the session. It is also recommended that the client_port and server_port parameters be specified further with the use of tags "rtp_port" and "rtcp_port" to handle the case where these ports are non-contiguous. -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 04:33:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28919 for ; Wed, 22 Oct 2003 04:33:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEQQ-0003Nm-EV for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 04:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9M8X2mZ012998 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 04:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEQP-0003NZ-UO for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 04:33: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 EAA28883 for ; Wed, 22 Oct 2003 04:32:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACEQM-00022V-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 04:32:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACEQM-00022S-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 04:32:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEQO-0003Mq-N3; Wed, 22 Oct 2003 04:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACEQJ-0003Lq-1g for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 04:32: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 EAA28880 for ; Wed, 22 Oct 2003 04:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACEQG-00022N-00 for mmusic@ietf.org; Wed, 22 Oct 2003 04:32:52 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1ACEQF-00022K-00 for mmusic@ietf.org; Wed, 22 Oct 2003 04:32:51 -0400 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9M8Wooq020118; Wed, 22 Oct 2003 10:32:50 +0200 Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id 45J5NHJC; Wed, 22 Oct 2003 10:36:48 +0200 Message-ID: <3F9640B0.4090408@ericsson.com> Date: Wed, 22 Oct 2003 10:32:48 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 References: <72263E8E8622D611975C0002B32C19D805A17BD1@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17BD1@misty.packetvideo.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 Thomas, If you have a use cases for this, I think it is possible to keep the timed functionality, under the condition that you provide all necessary specification text to solve the problems with timed PLAYs. I would also like to have some more information about use case. The big problem with the timed requests are the following: - Are they allowed to be stacked, are multiple possible to be requested for later execution? If yes, the real problems exist. - If you use timed requests how does the interaction happens with the state machine. When are the state transition made, when the request is received or when it is executed. - How is errors at the time of execution handled? - If multiple requests are allowed, how does one handle if two request collide. - How do you stop a timed request, between acceptance and execution? These are probably not all the problems, simply the ones I can remember of the top of my head. So please provide a solution proposal so we can discuss and review if it solves the problems in a satisfactory way. cheers Magnus Thomas Zeng wrote: > Magnus: > > During one of the telecon for RTSP, I recall that a decision was made to > deprecate "time=" parameter in Range header. > > We have found a use case in the context of playlist support, where we would > like to use > "time=" parameter in Range header in the PLAY request as designed in > RFC2326, quoted below: > > 10.5 PLAY > > ... > > The Range header may also contain a time parameter. This parameter > specifies a time in UTC at which the playback should start. If the > message is received after the specified time, playback is started > immediately. The time parameter may be used to aid in synchronization > of streams obtained from different sources. > > > > In light of this, would it be possible to retain this "time parameter"? > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 16:21:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26263 for ; Wed, 22 Oct 2003 16:21:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPTc-0006LH-5Y for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 16:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MKL4GS024375 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 16:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPTc-0006L4-2E for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 16:21: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 QAA26211 for ; Wed, 22 Oct 2003 16:20:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPTa-0002DI-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 16:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACPTZ-0002DE-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 16:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPTa-0006JZ-3k; Wed, 22 Oct 2003 16:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACPTQ-0006EJ-0w for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 16: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 QAA26203 for ; Wed, 22 Oct 2003 16:20:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACPTO-0002Cz-00 for mmusic@ietf.org; Wed, 22 Oct 2003 16:20:50 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1ACPTN-0002Ce-00 for mmusic@ietf.org; Wed, 22 Oct 2003 16:20:49 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1ACPTH-0007Gm-00; Wed, 22 Oct 2003 13:20:43 -0700 Date: Wed, 22 Oct 2003 13:20:43 -0700 From: Tom Marshall To: Colin Perkins Cc: mmusic@ietf.org Subject: Re: [MMUSIC] SDP b= clarification Message-ID: <20031022202043.GF19150@real.com> References: <20030902215852.GD1475@real.com> <1567E9F1-041B-11D8-B566-000A957FC5F2@csperkins.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7uYPyRQQ5N0D02nI" Content-Disposition: inline In-Reply-To: <1567E9F1-041B-11D8-B566-000A957FC5F2@csperkins.org> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --7uYPyRQQ5N0D02nI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >>The ABNF in draft-ietf-mmusic-sdp-new-13.txt explicitly allows > >>repetition. > >> > >> bandwidth-fields =3D *("b=3D" bwtype ":" bandwidth CRLF) > >> bwtype =3D token > >> bandwidth =3D 1*DIGIT > > > >Cool. Could we get a note in the text that corresponds with the ABNF? >=20 > Provided there are no objections, if you suggest explicit wording=20 > changes, I can incorporate them into -15. This would be the simplest change: --- draft-ietf-mmusic-sdp-new-14.txt 2003-10-22 12:51:26.000000000 -07= 00 +++ draft-ietf-mmusic-sdp-new-14-edited.txt 2003-10-22 13:18:57.00000= 0000 -0700 @@ -495,7 +495,7 @@ p=3D* (phone number) c=3D* (connection information - not required if included in all media) - b=3D* (bandwidth information) + b=3D* (zero or more bandwidth information lines) One or more time descriptions (see below) =20 =20 @@ -519,7 +519,7 @@ i=3D* (media title) c=3D* (connection information - optional if included at session-level) - b=3D* (bandwidth information) + b=3D* (zero or more bandwidth information lines) k=3D* (encryption key) a=3D* (zero or more media attribute lines) =20 --=20 Football combines the two worst features of American life. It is violence punctuated by committee meetings. -- George F. Will --7uYPyRQQ5N0D02nI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/luabqznSmcYu2m8RAvKEAKCELklJn6IYQi7VSjsWNBvb1x44NwCfbnGE o82ZmXAKW4+zzrAienWdGRk= =XTct -----END PGP SIGNATURE----- --7uYPyRQQ5N0D02nI-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 18:28:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01908 for ; Wed, 22 Oct 2003 18:28:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRST-0007zX-HI for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 18:28:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9MMS15L030715 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 18:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRST-0007zK-Dv for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 18:28: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 SAA01828 for ; Wed, 22 Oct 2003 18:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRSQ-0003PW-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 18:27:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACRSP-0003PT-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 18:27:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRSS-0007yu-B8; Wed, 22 Oct 2003 18:28:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACRRu-0007nD-Qm for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 18:27: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 SAA01784 for ; Wed, 22 Oct 2003 18:27:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACRRr-0003P4-00 for mmusic@ietf.org; Wed, 22 Oct 2003 18:27:23 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1ACRRq-0003P1-00 for mmusic@ietf.org; Wed, 22 Oct 2003 18:27:22 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1ACRRf-0007Ph-00; Wed, 22 Oct 2003 15:27:11 -0700 Date: Wed, 22 Oct 2003 15:27:11 -0700 From: Tom Marshall To: Magnus Westerlund Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP: Proposal to remove SETUP and TEARDOWN of individual media streams in PLAY state Message-ID: <20031022222711.GJ19150@real.com> References: <3F7C3C30.6060906@ericsson.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eWbcAUUbgrfSEG1c" Content-Disposition: inline In-Reply-To: <3F7C3C30.6060906@ericsson.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --eWbcAUUbgrfSEG1c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Oct 02, 2003 at 04:54:40PM +0200, Magnus Westerlund wrote: > Hi, >=20 > Another issue that was discussed on yesterdays telecon was the removal=20 > of the part specifying that usage of setup and teardown on individual=20 > media stream in PLAY state is possible. This does not effect the=20 > functionality for: >=20 > - SETUP and Teardown in ready state > - The usage of SETUP to change transport parameters. > - Usage of aggregated Teardown in play state to end session. >=20 > The removal of this functionality will be done in such way that it will= =20 > be possible in the future to specify this as extension functionality. I have a use case for this functionality, although I think it is probably best left to an extension tag. I'm interested in how it might be specified such that it's compatible with the core spec. --=20 Nothing is illegal if a hundred businessmen decide to do it, and that's true anywhere in the world. -- Andrew Young --eWbcAUUbgrfSEG1c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lwQ/qznSmcYu2m8RAssEAJsEJKfRskp1dj9LjfOY0Bm/anxFsACfbrFr fScgsqOZyhF6vwjHnk2oY2A= =qTtM -----END PGP SIGNATURE----- --eWbcAUUbgrfSEG1c-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 22 23:31:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16600 for ; Wed, 22 Oct 2003 23:31:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACWBk-0001sl-7V for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 23:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9N3V4ci007229 for mmusic-archive@odin.ietf.org; Wed, 22 Oct 2003 23:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACWBk-0001sW-2E for mmusic-web-archive@optimus.ietf.org; Wed, 22 Oct 2003 23:31: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 XAA16583 for ; Wed, 22 Oct 2003 23:30:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACWBh-00008f-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 23:31:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACWBh-00008c-00 for mmusic-web-archive@ietf.org; Wed, 22 Oct 2003 23:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACWBh-0001rK-V1; Wed, 22 Oct 2003 23:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACWBN-0001pJ-P0 for mmusic@optimus.ietf.org; Wed, 22 Oct 2003 23:30: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 XAA16571 for ; Wed, 22 Oct 2003 23:30:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACWBL-00008P-00 for mmusic@ietf.org; Wed, 22 Oct 2003 23:30:39 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1ACWBK-00008M-00 for mmusic@ietf.org; Wed, 22 Oct 2003 23:30:39 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 22 Oct 2003 20:30:21 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Wed, 22 Oct 2003 20:30:21 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Wed, 22 Oct 2003 20:29:06 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1ACWAa-0000Hz-00 for ; Wed, 22 Oct 2003 20:29:52 -0700 Date: Wed, 22 Oct 2003 20:28:29 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on goodfellas.real.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #102 - 5 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net) 2. [ rtspspec-Bugs-810666 ] Removal of SETUP in play state (SourceForge.net) 3. [ rtspspec-Bugs-810666 ] Removal of SETUP in play state (SourceForge.net) 4. [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP (SourceForge.net) 5. [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 22 Oct 2003 09:04:36 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state Bugs item #795295, was opened at 2003-08-26 14:08 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: TEARDOWN using * and the Ready-nm state Initial Comment: The 20 february 2002 we discussed http://rtsp.org/bug506412, for conclusion of that discussion see minutes: http://rtsp.org/2002/telecon/minutes20Feb.html However to me it seems that the need for state Ready-nm is not that great. Also the use of "*" as a URL will not work when proxies are present, unless requirements are put on them to maintain certain state in regards to sessions. The use of the presentation URL also is problematic as some sessions may not have a defined session URL, like for example for sessions intended to be used in non-aggregted mode. Therefore my suggestion is that the Ready-nm state is removed and that teardown using "*" is dissallowed. Comments please. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:04 Message: Logged In: YES user_id=302620 As no comments has been raised, this will be edited out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 22 Oct 2003 09:03:52 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-810666 ] Removal of SETUP in play state Bugs item #810666, was opened at 2003-09-22 17:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Removal of SETUP in play state Initial Comment: On MMUSIC there is a proposal to remove the functionality for setup in play state to add a new individual media stream. This not about changing transport parameters! First the need for this is not clear. The only use cases seems to be to do switching between different media streams variants. As this doesn't look as the best method and secondly that switching at all is an add on functionality this seem to not belong in core spec. Secondly removing this will simplify the specification writing. Third, if the method is need in the future it will be possible to write an extension specification. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:03 Message: Logged In: YES user_id=302620 No comment against this removal has been raised. Therefore this will be editied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 22 Oct 2003 09:30:01 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-810666 ] Removal of SETUP in play state Bugs item #810666, was opened at 2003-09-22 17:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 Category: None >Group: Resolved - Added to text Status: Open >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Removal of SETUP in play state Initial Comment: On MMUSIC there is a proposal to remove the functionality for setup in play state to add a new individual media stream. This not about changing transport parameters! First the need for this is not clear. The only use cases seems to be to do switching between different media streams variants. As this doesn't look as the best method and secondly that switching at all is an add on functionality this seem to not belong in core spec. Secondly removing this will simplify the specification writing. Third, if the method is need in the future it will be possible to write an extension specification. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:30 Message: Logged In: YES user_id=302620 The removal has now been performed and checked in in the following commit: /cvsroot/rtspspec/changes.tex,v <-- changes.tex new revision: 1.18; previous revision: 1.17 /cvsroot/rtspspec/iana.tex,v <-- iana.tex new revision: 1.14; previous revision: 1.13 /cvsroot/rtspspec/machine.tex,v <-- machine.tex new revision: 1.13; previous revision: 1.12 /cvsroot/rtspspec/methods.tex,v <-- methods.tex new revision: 1.33; previous revision: 1.32 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:03 Message: Logged In: YES user_id=302620 No comment against this removal has been raised. Therefore this will be editied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810666&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 22 Oct 2003 09:43:08 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-585865 ] Use of Date, and Host in RTSP Bugs item #585865, was opened at 2002-07-24 13:22 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194 Category: General >Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Use of Date, and Host in RTSP Initial Comment: There exist a number of HTTP headers that are just referenced into the specification. Several is hard to interpret on how they relate to RTSP and what requirement level that is needed. Date: The date header MUST be sent by origin server in responses. What is an origin server and what exceptions exist for RTSP? For RTSP does that include requests also? Host: The comment is that this should not be used in RTSP. This should be reflected in the heade table. Other headers that are simply referenced needs most probably some specification on applicability and exceptions. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:43 Message: Logged In: YES user_id=302620 The Host and Date header has both been clarified on there usage. Edits are checked in for both. The Date has been there for some versions, while the host text is new. If some other headers also needs edit, has not been evaluated at this time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=585865&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 22 Oct 2003 09:30:27 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-795295 ] TEARDOWN using * and the Ready-nm state Bugs item #795295, was opened at 2003-08-26 14:08 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 Category: None >Group: Resolved - Added to text Status: Open >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: TEARDOWN using * and the Ready-nm state Initial Comment: The 20 february 2002 we discussed http://rtsp.org/bug506412, for conclusion of that discussion see minutes: http://rtsp.org/2002/telecon/minutes20Feb.html However to me it seems that the need for state Ready-nm is not that great. Also the use of "*" as a URL will not work when proxies are present, unless requirements are put on them to maintain certain state in regards to sessions. The use of the presentation URL also is problematic as some sessions may not have a defined session URL, like for example for sessions intended to be used in non-aggregted mode. Therefore my suggestion is that the Ready-nm state is removed and that teardown using "*" is dissallowed. Comments please. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:30 Message: Logged In: YES user_id=302620 The removal has now been performed and checked in in the following commit: /cvsroot/rtspspec/changes.tex,v <-- changes.tex new revision: 1.18; previous revision: 1.17 /cvsroot/rtspspec/iana.tex,v <-- iana.tex new revision: 1.14; previous revision: 1.13 /cvsroot/rtspspec/machine.tex,v <-- machine.tex new revision: 1.13; previous revision: 1.12 /cvsroot/rtspspec/methods.tex,v <-- methods.tex new revision: 1.33; previous revision: 1.32 ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-22 18:04 Message: Logged In: YES user_id=302620 As no comments has been raised, this will be edited out. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=795295&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 23 23:24:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01153 for ; Thu, 23 Oct 2003 23:24:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsYb-00037x-8v for mmusic-archive@odin.ietf.org; Thu, 23 Oct 2003 23:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9O3O9kC012006 for mmusic-archive@odin.ietf.org; Thu, 23 Oct 2003 23:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsYa-00037L-Qz for mmusic-web-archive@optimus.ietf.org; Thu, 23 Oct 2003 23:24: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 XAA01143 for ; Thu, 23 Oct 2003 23:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACsYY-0004bV-00 for mmusic-web-archive@ietf.org; Thu, 23 Oct 2003 23:24:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ACsYY-0004bR-00 for mmusic-web-archive@ietf.org; Thu, 23 Oct 2003 23:24:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsYT-00036D-5K; Thu, 23 Oct 2003 23:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ACsYQ-00035W-FD for mmusic@optimus.ietf.org; Thu, 23 Oct 2003 23:23:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01130 for ; Thu, 23 Oct 2003 23:23:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ACsYJ-0004bG-00 for mmusic@ietf.org; Thu, 23 Oct 2003 23:23:51 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1ACsYI-0004bC-00 for mmusic@ietf.org; Thu, 23 Oct 2003 23:23:50 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 23 Oct 2003 20:23:28 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Thu, 23 Oct 2003 20:23:28 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Thu, 23 Oct 2003 20:22:03 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1ACsXJ-0007qQ-00 for ; Thu, 23 Oct 2003 20:22:49 -0700 Date: Thu, 23 Oct 2003 20:21:51 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on scarface.real.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #103 - 7 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-810678 ] How to indicate end of media stream (SourceForge.net) 2. [ rtspspec-Bugs-513753 ] RTSP extensions and IANA (SourceForge.net) 3. [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL (SourceForge.net) 4. [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification (SourceForge.net) 5. [ rtspspec-Bugs-531189 ] How does REDIRECT method work (SourceForge.net) 6. [ rtspspec-Bugs-500868 ] Require: option-tag values unclear (SourceForge.net) 7. [ rtspspec-Bugs-500906 ] Client liveness criteria vague (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:44:24 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-810678 ] How to indicate end of media stream Bugs item #810678, was opened at 2003-09-22 17:48 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810678&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: How to indicate end of media stream Initial Comment: discussed at the 57th IETF meeting 16th of July 2003. Issue: Possible methods for signalling end of stream/media (not session) in RTP. Discussion: Need to signal that a stream/media has ended exist mostly in unbound sessions. Proposal brought up to indicate this is RTCP BYE when the sender stops sending and has waited some time it can remove the SSRC of that source and send the BYE to indicate this. Another proposal was to send this information in RTSP methods. One could use sever to client TEARDOWN to indicate this session really are over, nothing more can be done. PAUSE can be sent when the media has been served but the client may rewind do other operations. The TEARDOWN idea was not liked as certain applications require session data to be sent from client to server using SET_PARAMETER. A new method should be evaluated. There might also exist significant synchronization problems in this. Resolution: Propose a RTSP extension with a new method. Thomas Zeng to write strawman proposal for evaluation to mailing list. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:44 Message: Logged In: YES user_id=302620 A strawman proposal is avail in this MMUSIC messge: https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg01978.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=810678&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:38:59 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513753 ] RTSP extensions and IANA Bugs item #513753, was opened at 2002-02-06 15:05 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: RTSP extensions and IANA Initial Comment: Today the RFC 2326 talks about extensions to RTSP and also has a number of headers that uses parameters. In the next version the following clarifications should be done: - Setup a IANA register for RTSP parameters. - Rules how to register different types of parameters. - What type of documents that are needed for extending RTSP. IANA registering of parameters. IETF RFC for new headers(?), methods and future protocol versions. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:38 Message: Logged In: YES user_id=302620 The IANA section is clearly needed. As it is has existed for quite a while this bug will be closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 18:17 Message: Logged In: YES user_id=302620 The IANA section has been exteneded to include what is currently all found values that need regestries. The rules and there levels needs further input. All x- things has been removed due to there evilness. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-05-27 16:52 Message: Logged In: YES user_id=302620 Most of the issues describe in this bug are now adressed in the new CVS repository file: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/iana.tex Some further work regarding parameters are also required. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:49:06 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640272 ] Default way of deriving aggregate URL Bugs item #640272, was opened at 2002-11-18 21:19 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Default way of deriving aggregate URL Initial Comment: Currently there is very little said on which aggregated control URL to use. The only given case is the a=control attribute in SDP at session level. In cases when one aggregates media stream that have no common SDP declaration or dependencies in other ways the URL can't be derived. Examples of such cases is when you would like to aggregate a session multiplexed retransmission stream with the original data stream, without requiring aggregatation between all media types part of a stream. Another example is aggregation of streams that are lacking a common SDP description but still can be intressting to aggregate. To fix this a way to derive what a valid aggregate URL is needs to be specified. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:49 Message: Logged In: YES user_id=302620 Currently I have written in the specification text that a client not having received a aggregated control URI SHOULD consider it as no aggregation available. However it does not rule out that one tries to create aggregated control. The rules for how to create the URI is present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:40 Message: Logged In: YES user_id=302620 In the IETF in Vienna discussion July 16th 2003: Issue: Missing session level control URI in SDP. IF the session control URI is missing, should we allow the client to try to to aggregate these? If aggregated which session control URI must be used. Discussion: This needs to be resolved. Tom Marshall did not thought that we should prevent the use case to aggregate unless necessary for interoperability. One possible resolution is to say that any media description missing session level control URI must be setup with individual RTSP session for each media stream and any synchronization between media be done on the receiver side. A practical resolution resolution could be: A client SHOULD follow the above statement but MAY try to aggregate. The server MAY allow this aggregation but MAY also refuse it using 4xx (Only non aggregated operation allowed). Resolution?: Session declarations lacking a session level control URL, MUST be used in non-aggregated control. Further discussion needed? ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: this is problem when aggregate control done in not obvious way # Magnus: what happens when you try to aggregate things that aren't designed to be aggregated # Joerg: I think this would require a lot of work to make this work correctly # Magnus: solution is to solve this with non-aggregate control # Tom: how does client know # Magnus: reuse session id # Tom: what happens when you pass the session id with a different URL # Rob: it should be undefined # Magnus: it should return error # Rob: that's no more backward compatible # Magnus: do you have proposed wording 11.4 second paragraph # RESOLUTION: Tom to write up wording for 11.4 second paragraph ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640272&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:29:40 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification Bugs item #493265, was opened at 2001-12-14 12:55 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Pause - Play behaviour clarification Initial Comment: The scenario is the following: A media stream is ready to start playing when the client does the following A-C A: PLAY range npt:10-30 B: @npt:22-> PAUSE C: PLAY (no range) This will result in resuming playing at npt:22. The unclearity is which of the following behaviour is the correct one? 1. Play until 30, i.e the second play is equal to PLAY range:22-30. 2. Play until end of media, i.e. the second play is equal to PLAY range:22- The RFC states the following in Section 10.6 third paragraph: "A PAUSE request discards all queued PLAY requests. However, the pause point in the media stream MUST be maintained. A subsequent PLAY request without Range header resumes from the pause point." The main unclarity is in what resumes means when also taking the first sentence into account. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:29 Message: Logged In: YES user_id=302620 This comment has been addressed by the general clarification of PLAY and PAUSE handling plus some furhter clarificiations. The specification text indicates that unless the second play request specify a range the server will play from the pause point of 22 second until the end of media. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-17 21:32 Message: Logged In: YES user_id=3796 I would be inclined toward the 22-end interpretation (your option 2). Won't change the spec until it's been covered by the group, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 06:10:28 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-531189 ] How does REDIRECT method work Bugs item #531189, was opened at 2002-03-18 05:14 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: How does REDIRECT method work Initial Comment: In the spec there is conflicting wording on what will happend when the server sends a REDIRECT to the client. In the state machine part the RFC says that the server should go to init state. Section 10.10 REDIRECT says that the client must do TEARDOWN on the session. How is it supposed to work espically combined with RANGE needs to be clarified also see #513891 ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:10 Message: Logged In: YES user_id=302620 At the telecons the 1 nov and 14th of nov 2003 the issue of implicit session removal was discussed. It was agreed that having it to remove the state was okay. However the handling of the signalling transport connection was more of an issue. A specification text proposal is now edited in. Please review to see if it is found acceptable. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 17:51 Message: Logged In: YES user_id=302620 From the 57th IETF meeting discussion 16th of July 2003: Issue: Should REDIRECT automatically close session. Discussion: This does not concern 3rr responses. As a connection related REDIRECT will terminate the session on the server side it is reasonable the same thing happens for REDIRECT request directed at the session. The exception to this is timed REDIRECTS that will continue exist until the specified time. The client should do TEARDOWN prior to this point to move the session to the alternative session. Resolution: Clarify that session will be terminated by a successful REDIRECT, independently of its connection or session. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-06-25 21:11 Message: Logged In: YES user_id=302620 There has been updated text on the use of REDIRECT. The usage of Range has also been clarified and solution for all use cases exist. Two issue remains regarding redirect. 1. Should acknowleging a REDIRECT request mean that the session is closed? Currently there exist on special case regarding the use of * in the request that indicates that transport link shall be closed, the session should be closed automatically. However for the other cases when sessions is targeted directly they are supposed to send a TEARDOWN for that session. 2. How should the client handle any outstanding request when it receives a REDIRECT request with *? ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-18 17:12 Message: Logged In: YES user_id=302620 The proposed solution for ranges does not work for content that uses UTC for positioning, like surveilance tapes. Suggestions on how to solve this, please. In case that the location header only contains a server adress the client may assume that the media is identical and does not need to send a DESCRIBE before setting up a new session. Otherwise it needs to do it as media may be different. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-12 15:12 Message: Logged In: YES user_id=302620 One more problem is that a client does not know if it should issue a play with the range where it was redirected or start from the begining. In the case of a media on deman and it gets identical media from the new server it seems more valid to resume at the position it was redirected at. However if it gets redirected to another media it should start from the beginng. And in the case of live media it should simply not use any range in its PLAY request. A mechanism needs to be added that solves this problem. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-09-12 15:08 Message: Logged In: YES user_id=302620 The result of a MMUSIC discussion is: 3xx Responses: The server should use this to signal the client that it should go find the media somewhere else. This answer can be used on the methods that do inquires regarding the media or tries to establish a session, i.e. OPTIONS (with media URL), DESCRIBE, SETUP, and perhaps ANNOUNCE. It should not be used when a server has an already established session and needs to move that session to another server, i.e. don't use them on PAUSE, PLAY, RECORD. The client after receiving a REDIRECT must restart its work on getting session information and setting up the session. REDIRECT request: This method shall be used when the server needs to move already established session from this server. So it shall not be used unless there is a session identifier to reference. The redirect request SHOULD use contain the session control URL and MUST include a session header. This enables the client a unambiguous identification of which session it should move. I don't know if the server should go directly to INIT after receiving the response from the client on the REDIRECT. This would allow the server to reclaim any resources as fast as possible. Alternatively the server should wait for a teardown, but this seem to waste a round trip of time. But as both behaviors are hinted in RFC 2326 it needs clarification. When a client has received a REDIRECT request and acknowledge the redirect it must assume that the session does no longer exist. The exception is if a range header was part of the request, and in that case it will be without a session at the specified moment. So after receiving a redirect the client must start from scratch to establish a new session at the given location. Use of location header: My opinion is that is should be a complete RTSP URL. Use of Range header: Also how the Range header shall be interpreted together with REDIRECT needs to be clarified. As the desired behavior may vary I think we need to be a little bit cleaver here. If a range header is included and contains a time in UTC it shall be interpreted that the server will serve this client until that UTC time, and after that time the client needs to establish a new session at the given location. If a SMPTE or NPT time is given the session will end when the playback reaches the given point in the media. So in the case the client rewinds to the start before reaching specified media point the session will remain. By using UTC time the server can signal that I can't handle your request further than e.g. until 18.00 today. Using NPT will allow a server to redirect a user due to limitations of the media, e.g. charging for rest of movie. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=531189&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:33:16 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-500868 ] Require: option-tag values unclear Bugs item #500868, was opened at 2002-01-08 17:09 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194 Category: None >Group: Resolved - Added to text Status: Open Resolution: None Priority: 5 Submitted By: Sean Sheedy (seansh) >Assigned to: Magnus Westerlund (magwes) Summary: Require: option-tag values unclear Initial Comment: The proper option-tag values to use in the Require: header when checking for optional features are not always clear. Some are more easily guessed then others. For example, to ask whether a server supports the Scale: header, I would guess that the proper option-tag would be "scale". However, how does a client ask whether the server supports the smpte time format in the Range: header? The document should include a table of optional features and their corresponding option-tag values. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:33 Message: Logged In: YES user_id=302620 The feature tags will be defined in the necessary specifications. All official tags will be stored in an IANA managed repository according the rules available in the IANA chapter of the core specification. The SMPTE range header question will be solved thorugh the use of Accept-Ranges instead of feature tags. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-29 04:26 Message: Logged In: YES user_id=3796 This should probably be a separately defined document. The Require header was intended as a way of querying for features outside of the scope of RTSP, rather than for features in RTSP. It is too late to require that existing implementations support new feature tags, but I agree it would be useful thing to have around. A candidate list may fall out of the list of features in RTSP. Sean, would you mind taking a first crack at creating the list of features tags you'd like to see? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:37:06 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-500906 ] Client liveness criteria vague Bugs item #500906, was opened at 2002-01-08 18:14 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open >Resolution: Accepted Priority: 5 Submitted By: Sean Sheedy (seansh) >Assigned to: Magnus Westerlund (magwes) Summary: Client liveness criteria vague Initial Comment: The current standard is vague about what constitutes a client "liveness" indication sufficient to prevent the media server from freeing a client's session. It also does not address under what circumstances a media server may close an inactive persistent control connection from a client. These areas should be more explicitly specified so that clients can reliably maintain their sessions with minimum liveness detection overhead. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:37 Message: Logged In: YES user_id=302620 As no comments on this bug has been raised in a year it will be closed. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 14:39 Message: Logged In: YES user_id=302620 The criteria for closing connections has been clarified in the chapter connections. The liveness signaling has also been clarified in the session header chapter. Changes are checked in. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-01-14 11:13 Message: Logged In: YES user_id=302620 Primary source of livness information is RTCP, which should be clarified. Secondly the new method PING could be used, see bug report #477400. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500906&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 15:38:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25958 for ; Fri, 24 Oct 2003 15:38:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7lA-0000R3-7g for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 15:38:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJc82f001669 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 15:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7l8-0000Qk-54 for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 15:38: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 PAA25951 for ; Fri, 24 Oct 2003 15:37:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7l6-0003AJ-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 15:38:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD7l5-0003AG-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 15:38:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7l3-0000QB-B3; Fri, 24 Oct 2003 15:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD7kk-0000JG-BF for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 15:37: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 PAA25944 for ; Fri, 24 Oct 2003 15:37:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD7ki-0003AC-00 for mmusic@ietf.org; Fri, 24 Oct 2003 15:37:40 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AD7ki-0003A4-00 for mmusic@ietf.org; Fri, 24 Oct 2003 15:37:40 -0400 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 24 Oct 2003 15:36:29 -0400 Message-ID: Thread-Topic: [ rtspspec-Bugs-810678 ] How to indicate end of media stream Thread-Index: AcOZ3ncsF+cJMrBsRAmWQuIk3pL9lwAhIG9A From: "Matthew Heaney" To: Cc: , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: rtspspec-bugs-request@lists.sourceforge.net=20 > [mailto:rtspspec-bugs-request@lists.sourceforge.net]=20 > Sent: Thursday, October 23, 2003 11:22 PM >=20 > Issue: Possible methods for signalling end of > stream/media (not session) in RTP. >=20 > Discussion: Need to signal that a stream/media has > ended exist mostly in unbound sessions. Proposal > brought up to indicate this is RTCP BYE when the sender > stops sending and has waited some time it can remove > the SSRC of that source and send the BYE to indicate > this. Another proposal was to send this information in > RTSP methods. One could use sever to client TEARDOWN to=20 > indicate this session really are over, nothing more can be=20 > done. PAUSE can be sent when the media has been served but=20 > the client may rewind do other operations. The TEARDOWN idea=20 > was not liked as certain applications require session data to=20 > be sent from client to server using SET_PARAMETER. A new=20 > method should be evaluated. There might also exist=20 > significant synchronization problems in this. >=20 > Resolution: Propose a RTSP extension with a new method. > Thomas Zeng to write strawman proposal for evaluation > to mailing list. We do this already in TrueCast using a special RTP header extension word. The RTSP spec says that when the play request has completed, you're supposed to automatically transition to the paused state, per RFC 2326 10.5 (p. 35). However, this doesn't really work, because it's impossible for a client to know which frame corresponds to the endpoint of the Range header of the PLAY response. In other words, if the client sees a delay in the receipt of a frame, it can't know whether this is because of a server issue, a network issue, or just that there are no more frames coming. So what we do instead is to send a special end-of-stream RTP packet, containing a single header extension word, once we've sent all the frames in the range specified in the original PLAY request. We remain in the PLAY state, and continue to send the special packet every 100ms, until the client either explicitly issues a PAUSE request, or sends a TEARDOWN. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 15:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26754 for ; Fri, 24 Oct 2003 15:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD82Y-0003Mw-3S for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 15:56:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OJu6oG012943 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 15:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD82Y-0003Mg-02 for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 15:56: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 PAA26732 for ; Fri, 24 Oct 2003 15:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD82W-0003QR-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 15:56:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD82W-0003QO-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 15:56:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD82T-0003LS-BW; Fri, 24 Oct 2003 15:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD825-0003Hi-B5 for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 15: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 PAA26682 for ; Fri, 24 Oct 2003 15:55:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD81r-0003PF-00 for mmusic@ietf.org; Fri, 24 Oct 2003 15:55:23 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AD81q-0003PC-00 for mmusic@ietf.org; Fri, 24 Oct 2003 15:55:22 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AD81p-0003xu-00; Fri, 24 Oct 2003 12:55:21 -0700 Date: Fri, 24 Oct 2003 12:55:21 -0700 From: Tom Marshall To: Matthew Heaney Cc: mmusic@ietf.org, zeng@PacketVideo.COM, magnus.westerlund@ericsson.com Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream Message-ID: <20031024195521.GH13908@real.com> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oox5VnwalALFvA7" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --2oox5VnwalALFvA7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Discussion: Need to signal that a stream/media has > > ended exist mostly in unbound sessions. Proposal > > brought up to indicate this is RTCP BYE when the sender > > stops sending and has waited some time it can remove > > the SSRC of that source and send the BYE to indicate > > this. Another proposal was to send this information in > > RTSP methods. One could use sever to client TEARDOWN to=20 > > indicate this session really are over, nothing more can be=20 > > done. PAUSE can be sent when the media has been served but=20 > > the client may rewind do other operations. The TEARDOWN idea=20 > > was not liked as certain applications require session data to=20 > > be sent from client to server using SET_PARAMETER. A new=20 > > method should be evaluated. There might also exist=20 > > significant synchronization problems in this. > >=20 > > Resolution: Propose a RTSP extension with a new method. > > Thomas Zeng to write strawman proposal for evaluation > > to mailing list. >=20 >=20 > We do this already in TrueCast using a special RTP header extension > word. >=20 > The RTSP spec says that when the play request has completed, you're > supposed to automatically transition to the paused state, per RFC 2326 > 10.5 (p. 35). However, this doesn't really work, because it's > impossible for a client to know which frame corresponds to the endpoint > of the Range header of the PLAY response. >=20 > In other words, if the client sees a delay in the receipt of a frame, it > can't know whether this is because of a server issue, a network issue, > or just that there are no more frames coming. >=20 > So what we do instead is to send a special end-of-stream RTP packet, > containing a single header extension word, once we've sent all the > frames in the range specified in the original PLAY request. We remain > in the PLAY state, and continue to send the special packet every 100ms, > until the client either explicitly issues a PAUSE request, or sends a > TEARDOWN. We also have an end-of-stream packet for our RDT transport. I'm not sure what we do with RTP but I can check if you're interested. It seems logical to me that this be communicated over the transport channel, not the control channel. A simple RTP extension like you mention would make a great proposal. Obviously not everyone here shares that view though... --=20 Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun --2oox5VnwalALFvA7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mYOpqznSmcYu2m8RAqo7AJ0RYULE0HT8cTf9kH6FWFWz6yDOigCfX+rN y6K/IVV8VHn0rQuaAC3lffY= =ijzm -----END PGP SIGNATURE----- --2oox5VnwalALFvA7-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 16:29:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28209 for ; Fri, 24 Oct 2003 16:29:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8YQ-0001hb-TS for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:29:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OKT2TX006537 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8YQ-0001hM-P8 for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 16:29: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 QAA28190 for ; Fri, 24 Oct 2003 16:28:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8YO-0003sH-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:29:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD8YO-0003sE-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8YP-0001gk-7e; Fri, 24 Oct 2003 16:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8Xt-0001dA-6G for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 16:28:29 -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 QAA28181 for ; Fri, 24 Oct 2003 16:28:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8Xr-0003s5-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:28:27 -0400 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AD8Xq-0003s2-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:28:26 -0400 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 24 Oct 2003 16:28:05 -0400 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream Thread-Index: AcOaaOiMG10GnAjxQB+mDun5UK/RDQAAP8MQ From: "Matthew Heaney" To: "Tom Marshall" Cc: , , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Tom Marshall [mailto:tmarshall@real.com]=20 > Sent: Friday, October 24, 2003 3:55 PM >=20 > We also have an end-of-stream packet for our RDT transport. =20 > I'm not sure > what we do with RTP but I can check if you're interested. >=20 > It seems logical to me that this be communicated over the=20 > transport channel, > not the control channel. A simple RTP extension like you=20 > mention would make > a great proposal. Obviously not everyone here shares that=20 > view though... It's not as simple as sending a normal RTCP packet with no other info (say, a BYE msg), because UDP packets can arrive in any order. Nor is it clear how the RTP and RTCP streams would even be synchronized in UDP. Even in TCP it would be kind of a pain. It might be possible to use an RTCP packet (with an APP command maybe?) to specify the sequence number and/or RTP timestamp of the last frame. But this might get hairy if the last frame can be consumed prior to receipt of the RTCP indicator. So I'm in agreement with you that using RTP to indicate EOS is probably simpler than the RTCP alternative. Note that this is typically how things are done anyway, ie. void f(const List& list) { ListNode* node =3D list.m_head; while (node !=3D 0) { // do something with node->m_item =20 node =3D node.m_next; } } Or at a higher level of abstraction: void g(const std::list& list) { typedef std::list::const_iterator iter_t; iter_t i =3D list.begin(); const iter_t j =3D list.end(); while (i !=3D j)=20 { // do something with *i ++i; } } _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 16:41:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28850 for ; Fri, 24 Oct 2003 16:41:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8k7-0004wJ-9o for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:41:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OKf7n6018979 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8k7-0004w2-5z for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 16:41: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 QAA28829 for ; Fri, 24 Oct 2003 16:40:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8k5-00045R-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:41:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD8k4-00045O-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:41:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8k0-0004uu-Vi; Fri, 24 Oct 2003 16:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8jd-0004sa-Ou for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 16:40: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 QAA28826 for ; Fri, 24 Oct 2003 16:40:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8jb-00045L-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:40:35 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AD8jb-00045A-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:40:35 -0400 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9OKdtio006703; Fri, 24 Oct 2003 13:39:55 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Oct 2003 13:39:55 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BE7@misty.packetvideo.com> From: Thomas Zeng To: "'Tom Marshall'" , Matthew Heaney Cc: mmusic@ietf.org, Thomas Zeng , magnus.westerlund@ericsson.com Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Fri, 24 Oct 2003 13:39:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: , my comments embedded. -----Original Message----- From: Tom Marshall [mailto:tmarshall@real.com] Sent: Friday, October 24, 2003 12:55 PM To: Matthew Heaney Cc: mmusic@ietf.org; zeng@PacketVideo.COM; magnus.westerlund@ericsson.com Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream > > Discussion: Need to signal that a stream/media has > > ended exist mostly in unbound sessions. Proposal > > brought up to indicate this is RTCP BYE when the sender > > stops sending and has waited some time it can remove > > the SSRC of that source and send the BYE to indicate > > this. Another proposal was to send this information in > > RTSP methods. One could use sever to client TEARDOWN to > > indicate this session really are over, nothing more can be > > done. PAUSE can be sent when the media has been served but > > the client may rewind do other operations. The TEARDOWN idea > > was not liked as certain applications require session data to > > be sent from client to server using SET_PARAMETER. A new > > method should be evaluated. There might also exist > > significant synchronization problems in this. > > > > Resolution: Propose a RTSP extension with a new method. > > Thomas Zeng to write strawman proposal for evaluation > > to mailing list. > > > We do this already in TrueCast using a special RTP header extension > word. > > The RTSP spec says that when the play request has completed, you're > supposed to automatically transition to the paused state, per RFC 2326 > 10.5 (p. 35). However, this doesn't really work, because it's > impossible for a client to know which frame corresponds to the endpoint > of the Range header of the PLAY response. > > In other words, if the client sees a delay in the receipt of a frame, it > can't know whether this is because of a server issue, a network issue, > or just that there are no more frames coming. > > So what we do instead is to send a special end-of-stream RTP packet, > containing a single header extension word, once we've sent all the > frames in the range specified in the original PLAY request. We remain > in the PLAY state, and continue to send the special packet every 100ms, > until the client either explicitly issues a PAUSE request, or sends a > TEARDOWN. [tz] Just curious: why not send BYE every 100 ms instead of a special packet? Is it because RTCP channel may not be allocated? We also have an end-of-stream packet for our RDT transport. I'm not sure what we do with RTP but I can check if you're interested. It seems logical to me that this be communicated over the transport channel, not the control channel. A simple RTP extension like you mention would make a great proposal. Obviously not everyone here shares that view though... [tz] A special RTP packet would work, provided re-transmission mechanism is in place for RTP over UDP. It is also required for each track. For an RTSP session with many tracks, it is not elegant not being able to signal end-of-stream for the aggregate session. Also if the transport is not RTP, what do we do? I don't think RTSP is tied to using RTP as transport, for example REAL uses RDT as transport. So if RTSP does not provide end-of-stream signalling, every potential transport would have to reinvent the wheel. Therefore I still think that although both RTSP end-of-stream signalling and special RTP extension can solve the problem, RTSP end-of-stream is more succinct and more "re-usable". The drawback, of course, is that RTSP end-of-stream requires persistent RTSP connection. -- Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 16:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28983 for ; Fri, 24 Oct 2003 16:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8ox-00063g-JD for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OKk7mu023282 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 16:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8ox-00063R-Fl for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 16:46: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 QAA28979 for ; Fri, 24 Oct 2003 16:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8ov-00049y-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:46:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AD8ov-00049v-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 16:46:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8or-0005zb-3U; Fri, 24 Oct 2003 16:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD8o8-0005uZ-Ma for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 16:45: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 QAA28949 for ; Fri, 24 Oct 2003 16:45:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD8o6-00049N-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:45:14 -0400 Received: from goodfellas.real.com ([207.188.7.218]) by ietf-mx with esmtp (Exim 4.12) id 1AD8o6-00048n-00 for mmusic@ietf.org; Fri, 24 Oct 2003 16:45:14 -0400 Received: from raven.dev.prognet.com ([::ffff:172.23.22.246]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Fri, 24 Oct 2003 13:44:38 -0700 Date: Fri, 24 Oct 2003 13:44:42 -0700 (PDT) From: Aaron Colwell X-X-Sender: aaron@raven.dev.prognet.com To: Tom Marshall cc: Matthew Heaney , mmusic@ietf.org, zeng@PacketVideo.COM, magnus.westerlund@ericsson.com Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of media stream In-Reply-To: <20031024195521.GH13908@real.com> Message-ID: 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 The RealServer sends it's own end of stream APP packet over the RTCP channel. This packet contains the sequence number and timestamp of the last packet in the stream. The sequence number allows the client to know when it has received the last packet of the stream. This can help it avoid shutting down the stream early if the EOS packet happens to arrive before the last packet in the stream. This is not a common case, but it could happen. I think the RealServer only sends five or less of the end of stream packets. I like the idea of periodically sending them until a PAUSE or TEARDOWN occurs. That seems like a better way to insure the client gets the packet. Should this EOS packet be on the RTP or RTCP channel? Currently the RealServer uses the RTCP channel because it had a mechanism to allow extensions that would be ignored by clients that don't understand the packet. I don't think there a mechanism for putting this type of packet on the RTP channel. Aaron On Fri, 24 Oct 2003, Tom Marshall wrote: > > > Discussion: Need to signal that a stream/media has > > > ended exist mostly in unbound sessions. Proposal > > > brought up to indicate this is RTCP BYE when the sender > > > stops sending and has waited some time it can remove > > > the SSRC of that source and send the BYE to indicate > > > this. Another proposal was to send this information in > > > RTSP methods. One could use sever to client TEARDOWN to > > > indicate this session really are over, nothing more can be > > > done. PAUSE can be sent when the media has been served but > > > the client may rewind do other operations. The TEARDOWN idea > > > was not liked as certain applications require session data to > > > be sent from client to server using SET_PARAMETER. A new > > > method should be evaluated. There might also exist > > > significant synchronization problems in this. > > > > > > Resolution: Propose a RTSP extension with a new method. > > > Thomas Zeng to write strawman proposal for evaluation > > > to mailing list. > > > > > > We do this already in TrueCast using a special RTP header extension > > word. > > > > The RTSP spec says that when the play request has completed, you're > > supposed to automatically transition to the paused state, per RFC 2326 > > 10.5 (p. 35). However, this doesn't really work, because it's > > impossible for a client to know which frame corresponds to the endpoint > > of the Range header of the PLAY response. > > > > In other words, if the client sees a delay in the receipt of a frame, it > > can't know whether this is because of a server issue, a network issue, > > or just that there are no more frames coming. > > > > So what we do instead is to send a special end-of-stream RTP packet, > > containing a single header extension word, once we've sent all the > > frames in the range specified in the original PLAY request. We remain > > in the PLAY state, and continue to send the special packet every 100ms, > > until the client either explicitly issues a PAUSE request, or sends a > > TEARDOWN. > > We also have an end-of-stream packet for our RDT transport. I'm not sure > what we do with RTP but I can check if you're interested. > > It seems logical to me that this be communicated over the transport channel, > not the control channel. A simple RTP extension like you mention would make > a great proposal. Obviously not everyone here shares that view though... > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 17:18:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00345 for ; Fri, 24 Oct 2003 17:18:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9JX-00044Z-RM for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 17:17:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9OLHhAX015650 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 17:17:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD9JX-00044K-NA for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 17:17: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 RAA00203 for ; Fri, 24 Oct 2003 17:17:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD9JR-0004Yv-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 17:17:37 -0400 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AD9JQ-0004Y9-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 17:17:36 -0400 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AD96Q-00011P-GG for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 17:04:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD96H-00014r-Pb; Fri, 24 Oct 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AD95Q-0000sF-Ky for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 17:03: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 RAA29767 for ; Fri, 24 Oct 2003 17:02:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AD95O-0004Pz-00 for mmusic@ietf.org; Fri, 24 Oct 2003 17:03:06 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AD95N-0004Pw-00 for mmusic@ietf.org; Fri, 24 Oct 2003 17:03:05 -0400 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AD95N-00043a-00; Fri, 24 Oct 2003 14:03:05 -0700 Date: Fri, 24 Oct 2003 14:03:05 -0700 From: Tom Marshall To: Thomas Zeng Cc: Matthew Heaney , mmusic@ietf.org, magnus.westerlund@ericsson.com Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Message-ID: <20031024210305.GK13908@real.com> References: <72263E8E8622D611975C0002B32C19D805A17BE7@misty.packetvideo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="72k7VsmfIboquFwl" Content-Disposition: inline In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17BE7@misty.packetvideo.com> User-Agent: Mutt/1.5.4i Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --72k7VsmfIboquFwl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > So what we do instead is to send a special end-of-stream RTP packet, > > containing a single header extension word, once we've sent all the > > frames in the range specified in the original PLAY request. We remain > > in the PLAY state, and continue to send the special packet every 100ms, > > until the client either explicitly issues a PAUSE request, or sends a > > TEARDOWN. >=20 > [tz] Just curious: why not send BYE every 100 ms instead of a special > packet? Is it because > RTCP channel may not be allocated? My understanding is that if you send BYE, the RTP session is closed. The player should be allowed to continue using the session with another PLAY request. > We also have an end-of-stream packet for our RDT transport. I'm not sure > what we do with RTP but I can check if you're interested. >=20 > It seems logical to me that this be communicated over the transport chann= el, > not the control channel. A simple RTP extension like you mention would m= ake > a great proposal. Obviously not everyone here shares that view though... > [tz] A special RTP packet would work, provided re-transmission mechanism = is=20 > in place for RTP over UDP. It is also required for each track. For a= n=20 > RTSP session with many tracks, it is not elegant not being able to= =20 > signal end-of-stream for the aggregate session. Why is this not elegant? It keeps transport signalling in the transport and control signalling in the control channel. I think mixing them is less elegant. In my experience, the tracks don't always end at exactly the same time anyway (though they are usually well within one second of each other). > Also if the transport is not RTP, what do we do? I don't think=20 > RTSP is tied to using RTP as transport, for example REAL uses RDT as= =20 > transport. =20 > So if RTSP does not provide end-of-stream signalling, every potential > transport would have to reinvent the wheel. That should be the least of the transport inventors' worries. It just slipped by in RTP because RTP was invented primarily for multicast live and predates RTSP by a couple of years. > Therefore I still think that although both RTSP end-of-stream > signalling and special > RTP extension can solve the problem, RTSP end-of-stream is more > succinct and more > "re-usable". The drawback, of course, is that RTSP end-of-stream > requires persistent > RTSP connection. I thought the current spec was steering us away from persistent connections= ?=20 Requiring a persistent connection to properly receive an end-of-stream notification seems to be a step backward. --=20 To use violence is to already be defeated. -- Chinese proverb --72k7VsmfIboquFwl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/mZOJqznSmcYu2m8RAmgsAJ9bT6gsMfH+h+oXkjD5SlA6GrSzgACeP/9Q X3NNHGtjBQY5ClQcTxzm8bk= =tsCE -----END PGP SIGNATURE----- --72k7VsmfIboquFwl-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 24 23:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10648 for ; Fri, 24 Oct 2003 23:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF9u-0002Aw-MP for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 23:32:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P3WAF6008362 for mmusic-archive@odin.ietf.org; Fri, 24 Oct 2003 23:32:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF9u-0002An-5Y for mmusic-web-archive@optimus.ietf.org; Fri, 24 Oct 2003 23: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 XAA10638 for ; Fri, 24 Oct 2003 23:31:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADF9r-0000MX-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 23:32:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADF9r-0000MS-00 for mmusic-web-archive@ietf.org; Fri, 24 Oct 2003 23:32:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF9k-0002A2-Lu; Fri, 24 Oct 2003 23:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADF9R-00029M-40 for mmusic@optimus.ietf.org; Fri, 24 Oct 2003 23:31: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 XAA10628 for ; Fri, 24 Oct 2003 23:31:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADF9O-0000M7-00 for mmusic@ietf.org; Fri, 24 Oct 2003 23:31:38 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1ADF9N-0000M4-00 for mmusic@ietf.org; Fri, 24 Oct 2003 23:31:37 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 24 Oct 2003 20:31:19 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Fri, 24 Oct 2003 20:31:19 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Fri, 24 Oct 2003 20:29:44 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1ADF8I-0006tm-00 for ; Fri, 24 Oct 2003 20:30:30 -0700 Date: Fri, 24 Oct 2003 20:29:01 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on scarface.real.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #104 - 7 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-522602 ] Should Allow S->C "Teardown" (SourceForge.net) 2. [ rtspspec-Bugs-829528 ] SDP appendix and RFC 3388 (SourceForge.net) 3. [ rtspspec-Bugs-539001 ] Transport header should override m= (SourceForge.net) 4. [ rtspspec-Bugs-500875 ] State diagram clarifications (SourceForge.net) 5. [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready (SourceForge.net) 6. [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved (SourceForge.net) 7. [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:41:57 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-522602 ] Should Allow S->C "Teardown" Bugs item #522602, was opened at 2002-02-25 20:38 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=522602&group_id=23194 Category: General Group: Fix for DS - Need WG Input >Status: Closed Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) >Assigned to: Magnus Westerlund (magwes) Summary: Should Allow S->C "Teardown" Initial Comment: Table 2 in section 10 of RFC2326 seem to disallow S->C Teardown. And section 10.7 is vague on whether S->C teardown is OK. This should be relaxed, because Server might have to use TEARDOWN to tell client a live session is over. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:41 Message: Logged In: YES user_id=302620 As it is being take care of and new tracking bug 810678 will be used for this issues instead. ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2003-09-30 06:10 Message: Logged In: YES user_id=20397 Since during Vienna IETF, we have decided to add END_OF_STREAM, Teardown from S->C is not necessary. We can close this issue. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 18:52 Message: Logged In: YES user_id=302620 To be discussed ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=522602&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 04:38:46 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-829528 ] SDP appendix and RFC 3388 Bugs item #829528, was opened at 2003-10-24 13:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=829528&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: SDP appendix and RFC 3388 Initial Comment: Should we add text in the SDP chapter on how to handle the Grouping of media lines for SDP, RFC 3388? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=829528&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 05:20:08 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-539001 ] Transport header should override m= Bugs item #539001, was opened at 2002-04-04 01:32 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) Summary: Transport header should override m= Initial Comment: Section C.1.7 ("Connection Information") states the following: "for on-demand unicast streams and some multicast streams, the destination is specified by the client via the SETUP request". The rest of this section mainly refers to the "c=" line in SDP, but it's not clear that the SETUP Transport header also overrides the port given in the m= line. Clarification of this is needed. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:20 Message: Logged In: YES user_id=302620 This has been clarified in the SDP appendix. There has been alignment between what is possible between ports and addresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 07:35:20 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-500875 ] State diagram clarifications Bugs item #500875, was opened at 2002-01-08 17:17 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500875&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Sean Sheedy (seansh) >Assigned to: Magnus Westerlund (magwes) Summary: State diagram clarifications Initial Comment: My understanding is that the state diagram in Appendix A is per-session, not per-client. However, this is not explicitly stated. This should be made clear in the description. Errors within the media server (series 5xx) often leave a stream in an unplayable, unrecoverable state in which the client's only option is to tear down the session and start over. This should be reflected in the state diagram. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 16:35 Message: Logged In: YES user_id=302620 I hope that the resolution in the state machine chapter is satisfactory. AS no comments on the resolution has been given in the last year I hereby close the bug. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 13:30 Message: Logged In: YES user_id=302620 The state machine has been updated and clearly represent a RTSP session. The effect 5xx error codes may have has also been clarified. A 5xx response is in general recoverable from. But the server is allowed to terminate the session for errors of unrecoerable nature. The client will detect this when issuing another request to that session and receive a 454 (Session Not Found) as response. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-01-14 11:08 Message: Logged In: YES user_id=302620 This one is realted to bug report #500803 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=500875&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 04:51:03 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-556295 ] Client issues PAUSE while server ready Bugs item #556295, was opened at 2002-05-15 14:12 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Magnus Westerlund (magwes) Summary: Client issues PAUSE while server ready Initial Comment: 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? There appear to be two possible correct behaviors: 1. server responds with OK because it does not change state and does no harm. 2. server responds with error 455 because PAUSE does not make sense in this state. Both interpretations have been implemented. The latter appears to be more correct, but a client that assumes the first may misbehave if the server implements the second. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 13:51 Message: Logged In: YES user_id=302620 This clarification of behavior has now beend added to the text and will be published in v5. The text is in the state machine and pause method section. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-14 17:17 Message: Logged In: YES user_id=302620 The working assumption is that a 200 OK should be sent even if already in ready state. Also the pause point needs to be included in the response. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:16 Message: Logged In: YES user_id=302620 This should be clarified. Input from implementors wanted. The resolution should be made evident in the state machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=556295&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 09:14:10 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-662436 ] RTP/AVP/TCP w/o interleaved Bugs item #662436, was opened at 2003-01-05 03:01 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194 >Category: Feature Request >Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: RTP/AVP/TCP w/o interleaved Initial Comment: If a Transport line specifies RTP/AVP/TCP and does not also use the interleaved parameter, the transport setup details seem undocumented (maybe I'm not looking in the right place ...). I'm thinking of the level of detail the comedia I-D provides for TCP: which side accept()s and which side connect()s, how many connections to set up, framing, etc. Are there pre-existing implementations that use this transport mode? I happened to stumble onto this in writing the TCP appendix for the MWPP "implementation guidelines" ... which may spawn off a generic I-D specifying how to use comedia with RTP (framing, specifying the fmt tokens after TCP, etc). So, one option is to add RTP/AVP/TCP w/o interleaving details to that I-D, if adding it to to the RTSP I-D isn't desirable for some reason ... john lazzaro -- lazzaro@cs.berkeley.edu ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2003-05-28 18:34 Message: Logged In: YES user_id=3796 From 14 May 2003 telecon (http://rtsp.org/2003/telecon/minutes14May.html): # Magnus: we should leave this until RTP framing is done # Magnus: this is basically a feature request # Magnus: this might well be a separate draft # Rob: agreed # Aravind: agreed # Tom: we'll have to deal with this issue when DCCP comes along # Anders: I saw this in use # Tom: they might be using interleaving or not # RESOLUTION: separate draft for non-interleaving; narrow spec for interleaving ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=662436&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 05:07:50 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625352 ] Synchronising multiple SSRCs Bugs item #625352, was opened at 2002-10-18 20:41 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194 >Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Go Hori (ghori) >Assigned to: Magnus Westerlund (magwes) >Summary: Synchronising multiple SSRCs Initial Comment: taken from a thread in mmusic We have a problem in RTSP when a media stream needs to contain multiple RTP SSRCs. This can't be expressed today clearly. When one is only interested in controlling the media and not each individual source the following scenarios should be supported: A SINGLE SETUP request can result in one of the following: 1. A media stream with a single SSRC. 2. A media stream with retransmission with SSRC multiplexing. This requires a SSRC for the original and one for the retransmission packets. It is an advantage if both can be explicitly signalled, but is no requirement. 3. Live session with any number of participants and unlimited use of dynamic chosen SSRCs. Due to clients capability the different scenarios need to be explicitly signaled. Scenario 2 will be that from an SDP description and support of retransmission will be signaled by requesting AVPF in the transport header. However today there exist no way to signal if it is scenario 1 or 3. So this needs to be resolved in a nice backwards compatible way. I think that support for 3 can require support for any extra signaling while scenario 1 must work without any extra parts. By doing all these scenarios with a single SETUP per media stream we keep the signaling to a minimum and avoid further requirements on SDP. It might be advantageous in the future to create a SDP attribute declaring the streams type. If one desires to control the individual source one either declare individual media streams for each source. This will require use of ANNOUNCE in dynamic settings. The alternative would be to create a new media resource control protocol which is suited for this. However I don't see real need to solve this problem in standard RTSP better than by using ANNOUNCE. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:07 Message: Logged In: YES user_id=302620 This was discussed in the telecon the 28th April 2003. The resolution was to clarify in RTSP that only a single SSRC one can be given in RTSP. Any furhter SSRC may be present in the stream, however they must be synchronised using RTCP. This has been clarified in the specification. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625352&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Oct 25 02:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26366 for ; Sat, 25 Oct 2003 02:14:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADHge-0003Zp-2b for mmusic-archive@odin.ietf.org; Sat, 25 Oct 2003 02:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9P6E7vE013750 for mmusic-archive@odin.ietf.org; Sat, 25 Oct 2003 02:14:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADHgd-0003Zf-Ln for mmusic-web-archive@optimus.ietf.org; Sat, 25 Oct 2003 02:14: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 CAA26323 for ; Sat, 25 Oct 2003 02:13:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADHgZ-0001XO-00 for mmusic-web-archive@ietf.org; Sat, 25 Oct 2003 02:14:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADHgZ-0001XL-00 for mmusic-web-archive@ietf.org; Sat, 25 Oct 2003 02:14:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADHgZ-0003Ys-Dz; Sat, 25 Oct 2003 02:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADHfx-0003Tu-Np for mmusic@optimus.ietf.org; Sat, 25 Oct 2003 02:13: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 CAA26254; Sat, 25 Oct 2003 02:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADHfu-0001XC-00; Sat, 25 Oct 2003 02:13:22 -0400 Received: from coyote.icir.org ([192.150.187.37]) by ietf-mx with esmtp (Exim 4.12) id 1ADHft-0001X4-00; Sat, 25 Oct 2003 02:13:21 -0400 Received: from coyote.icir.org (localhost [127.0.0.1]) by coyote.icir.org (8.12.9p1/8.12.3) with ESMTP id h9P6DMp0067727; Fri, 24 Oct 2003 23:13:22 -0700 (PDT) (envelope-from kohler@coyote.icir.org) Message-Id: <200310250613.h9P6DMp0067727@coyote.icir.org> To: dccp@ietf.org cc: mmusic@ietf.org Date: Fri, 24 Oct 2003 23:13:22 -0700 From: Eddie Kohler Subject: [MMUSIC] DCCP, TFRC, and VoIP issue summary 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 all, Several months ago, we had a pretty lively discussion on these lists about why TFRC and/or DCCP might be inappropriate for VoIP and other apps. I wanted to summarize again the problems that people have brought up, and where we stand on solutions. Comments welcome. A. Complexity The existing DCCP specification is simply too complex for resource- constrained implementations, which might be common for voice. * This complexity seems important and not onerous for host stacks. We hope that CCID 3-Thin shows it's possible to simplify DCCP's requirements for resource-constrained implementations without radical surgery on the base protocol. B. Slow-start TCP-friendly congestion control algorithms must slow-start up to their sustained rate. Voice apps might like to start with their full bandwidth right away. Plus, the initial TFRC rate seems very slow (1 packet per RTT). * We have updated the CCID 3 draft to allow initial TFRC rates of up to 4 packets per RTT (or 4380 payload bytes per RTT), in line with recent TCP practice (RFC 3390). For a This supports a 40ms _initial_ packetization interval for any RTT up to 160ms: not bad at all. And we might consider allowing a larger initial window when packet payloads are small; this would require a bit of research on whether many small packets is actually equivalent to few large packets in terms of congestion. C. Rate slows down during idle periods The TFRC allowed sending rate will drop down to something very small (2-4 packets/RTT) when the sender is idle. This may cause problems particualrly with VoIP conversations, which are naturally idle-one-way then idle-the-other-way. The rampup from the small rate to the fair rate may take several to many RTTs, ouch. * The solution for slow start applies here. Beyond that, we recommend sending probe packets if any slowdown during an idle period is unacceptable; you don't get to reserve bandwidth in the best-effort internet. These probe packets could easily consist of required acknowledgements. D. Rate will not increase during app-limited period If the application is sending at rate R, the allowed rate will not increase much beyond R (say, more than 2R) until the app "probes" by transmitting at a faster rate. The reason: DCCP determines the allowable maximum rate by monitoring packet drops. Thus, DCCP "can not tell the application when to increase its rate unless the application 'probes' the network first by ... increasing its rate." (Phillipe Gentric) * A related issue, and again, we can't do much better in the current internet than having the application send probe packets: you don't get to reserve bandwidth you aren't using. Nevertheless, there shouldn't be much problem with the sender abruptly doubling its sending rate in this situation, assuming TFRC's observed loss event rate is low enough to allow it. E. Congestion control means variable rate Must an application with discrete sending rates send at a rate strictly bounded by TFRC's allowed rate? Could we allow some flexibility, so that it could send at, say, any rate <= 1.8*TFRC_allowed_rate? * There probably wouldn't be any problem with this, but it should be explored in a separate document. Does anyone want to write up a draft about CCID 3 adapted for a sender with discrete sending rates? F. Rate changes/oscillations There are application costs, possibly significant ones, associated with changing rates. Current codecs switch rates poorly; actual devices tend to swap in a new codec. Also, for audio at least, people find the glitches caused by frequent rate changes distracting. Thus, if the application has to change its rate frequently, because of CC, that's a problem. * A solution to issue D would apply here. Furthermore, we should not solve this problem generically; different applications will want different behavior. For example, Tom Phelan described a procedure where bandwidth is probed at the beginning of the connection, then a codec starts at a lower rate than the probe rate; if congestion causes the rate to drop below this, the connection terminates. G. Multiple streams An application that had both audio and video to send might use 2 DCCP connections. Could the application choose how its bandwidth is allocated among those connections? (Phillipe Gentric) * We haven't made progress on this. It's at least somewhat problematic since the end nodes can't necessarily assume that the two connections take the same path, with the same quality of service on all parts of the path. Here are some non-issues: things people have brought up that I think the DCCP spec already handles well. H. Low delay It's very important to minimize packetization overhead and effects of the send buffer. * An API issue, and DCCP was designed with this in mind. I. Control over the send buffer What happens when packets need to be dropped (because TFRC demands a lower rate than the application wants)? Some would like packets to be dropped by the TFRC stack, either by dropping the first packet, or the last packet, or the lowest-priority packet; others would like the application to be in direct control. * This is an API issue, and DCCP seems flexible enough to handle any of those APIs, or others. J. Pushing against the maximum rate (streaming media) TFRC always pushes against its maximum rate until a loss, which will force a decrease in the allowable rate. This induces periodic distortion. Can we minimize this by providing TFRC with a maximum rate, beyond which it will not push? (Damon Lanphear) * Absolutely---TFRC will not send more data than the application provides. Eddie _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Oct 26 00:24:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24964 for ; Sun, 26 Oct 2003 00:24:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADcRr-0001mb-0z for mmusic-archive@odin.ietf.org; Sun, 26 Oct 2003 00:24:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9Q4OEbr006847 for mmusic-archive@odin.ietf.org; Sun, 26 Oct 2003 00:24:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADcRq-0001mB-Fj for mmusic-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 00:24: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 AAA24904 for ; Sun, 26 Oct 2003 00:24:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADcRn-0006o3-00 for mmusic-web-archive@ietf.org; Sun, 26 Oct 2003 00:24:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADcRm-0006nY-00 for mmusic-web-archive@ietf.org; Sun, 26 Oct 2003 00:24:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADcRg-0001gn-E5; Sun, 26 Oct 2003 00:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADbaI-000559-BJ for mmusic@optimus.ietf.org; Sat, 25 Oct 2003 23:28: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 XAA23992 for ; Sat, 25 Oct 2003 23:28:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADbaG-00068k-00 for mmusic@ietf.org; Sat, 25 Oct 2003 23:28:52 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1ADbaF-00068h-00 for mmusic@ietf.org; Sat, 25 Oct 2003 23:28:51 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sat, 25 Oct 2003 20:28:32 -0700 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.218] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Sat, 25 Oct 2003 20:28:31 -0700 (PDT) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Sat, 25 Oct 2003 20:27:06 -0700 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1ADbZG-0006nF-00 for ; Sat, 25 Oct 2003 20:27:50 -0700 Date: Sat, 25 Oct 2003 20:24:51 -0700 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on capefear.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #105 - 10 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla (SourceForge.net) 2. [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples (SourceForge.net) 3. [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP (SourceForge.net) 4. [ rtspspec-Bugs-803064 ] Teardown text needs rewrite (SourceForge.net) 5. [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session (SourceForge.net) 6. [ rtspspec-Bugs-619421 ] Range header in PLAY response (SourceForge.net) 7. [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. (SourceForge.net) 8. [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause (SourceForge.net) 9. [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 (SourceForge.net) 10. [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 09:11:54 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-640848 ] umbiguity in aggregate/non-aggregate pla Bugs item #640848, was opened at 2002-11-19 19:24 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Go Hori (ghori) >Assigned to: Magnus Westerlund (magwes) Summary: umbiguity in aggregate/non-aggregate pla Initial Comment: It is not clear to me who's choice it is to pick aggregate play vs. non-aggregate play. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 18:11 Message: Logged In: YES user_id=302620 No comments has been given for this since my last comment. I have edited this into the specification. Will be available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-03-12 15:45 Message: Logged In: YES user_id=302620 It is the clients. With the updated specification the client chooses this by setting up multiple streams or not in a each session. This has no impact on a server that supports aggregated control. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=640848&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 01:40:56 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-464462 ] Content-Length header wrong in examples Bugs item #464462, was opened at 2001-09-24 18:09 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194 >Category: Editorial Group: Fix for DS - Typo/Thinko Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Content-Length header wrong in examples Initial Comment: In most of the examples the Content-Length header is not the right value for the actual content of the header. like the one below,which I copied from RTSP 14.5, this number doeas not match: In this case here they write "44", but if you count (together with CRLF, or even just LF) 103 chars + 8 for CRLF or 4 for just LF. M-C: RTSP/1.0 200 1 OK Content-type: application/sdp Content-Length: 44 v=0 o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session i=See above t=0 0 m=audio 0 RTP/AVP 0 C-M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0 CSeq: 2 Transport: RTP/AVP;multicast;destination=225.219.201 .............................. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 10:02 Message: Logged In: YES user_id=302620 These must be fixed in all examples as soon as the updates becomes more stable. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=464462&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 06:39:15 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625339 ] need clarification for stand alone SDP Bugs item #625339, was opened at 2002-10-18 19:57 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194 >Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Go Hori (ghori) >Assigned to: Magnus Westerlund (magwes) >Summary: need clarification for stand alone SDP Initial Comment: When a SDP file is download other than via RTSP (e.g. HTTP, FTP), control strings need to be all absolute. Should probably put clarification or give an example for this case to avoid confusion. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 15:39 Message: Logged In: YES user_id=302620 There has been added a new section in the SDP appendix which writes some clarifying notes on the topic. Text will become available in v5. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:38 Message: Logged In: YES user_id=302620 Yes, this is another pice of information that belong to appendix C. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625339&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 09:03:02 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-803064 ] Teardown text needs rewrite Bugs item #803064, was opened at 2003-09-09 13:20 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=803064&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Teardown text needs rewrite Initial Comment: The text for the teardown section needs a serious rewrite. The current text is not very clear on several matters in regards to aggregated and non-aggregated teardown. Should probably await resolution of bug 795295. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 18:03 Message: Logged In: YES user_id=302620 I have now updated the text about the TEARDOWN section. It needs review. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=803064&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 08:42:30 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-772330 ] Clarify that RTCP shall be sent during whole session Bugs item #772330, was opened at 2003-07-16 16:09 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Magnus Westerlund (magwes) Summary: Clarify that RTCP shall be sent during whole session Initial Comment: Appendix B should be clarified to point out that RTCP is expected to be sent from succesful response of SETUP until TEARDOWN. During PAUSE the server and client should both continue to send RTCP as normal. Motivations to this behavior is: - to avoid timing out SSRC, - ensure detection of packet loss at the end of stream. - ensure that RTCP syncrhonization can work (necessary for multiple SSRC). - Ensure that RTP stream work prior to PLAY if there is some delay between them. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 17:42 Message: Logged In: YES user_id=302620 A clarification about this has been written into appendix B. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-07-16 16:12 Message: Logged In: YES user_id=302620 At the same time it should be made clear the RTCP BYE is sent when the session is terminated, i.e. at the time of teardown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=772330&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 05:27:55 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-619421 ] Range header in PLAY response Bugs item #619421, was opened at 2002-10-07 01:14 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Magnus Westerlund (magwes) Summary: Range header in PLAY response Initial Comment: Current RTSP RFC makes Range header in PLAY response from server optional. If the PLAY request includes a Range header indicating a possible seek, then it is probably necessary to include Range in the response since it is possible that the requested seek position could not be honored and playback will resume at the nearest seekable point which is not known to the client. Note: To fix this issue in 3GPP, Range in a PLAY response was made mandatory for all PLAY responses. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 14:27 Message: Logged In: YES user_id=302620 The inclusion of the Range header in PLAY responses is now a MUST. We haven't found any problem with this. If anybody finds this, please raise it. I have also put in Maureen into the acknowledgement section. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-01-31 13:49 Message: Logged In: YES user_id=302620 As discussed in the teleconf the 22 jan 2003: We should look at strengting the requirement on having the Range header also for live streams when using RTP. A solution based on Range:npt=now- with optional time or using Range:clock=x can work. But careful wording is required. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:06 Message: Logged In: YES user_id=3796 One other thing...put Maureen Chesire in the acknowlegements for raising this.... ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-11-20 21:02 Message: Logged In: YES user_id=3796 Per a conversation with Magnus and I, we think we should soften the language somewhat (strong SHOULD instead of MUST). One case to consider is a live stream, which one would think would obviate the need for this header. However, the rationale for having it in live is when dealing with RTP. Since RTP audio and video streams can have a completely different timestamp base, there needs to be an out-of-band technique for synchronization. The two techniques used in RTSP are: 1. RTSP "Range:"<->RTSP "RTP-Info:"<->RTP timestamp synch 2. RTCP timestamp<->NTP mapping Eventually, a well-behaved RTSP client will synch the streams based on the RTCP timestamps (when received). However, there's a period before the first RTCP packet arrives that there's no sync, unless a Range header is known. So, that also points to what the Range header should look like. The Range header should include an open-ended wallclock range, like so: Range: clock=20021120T133205Z- RTP-Info:url=rtsp://example.com/fizzle/audiotrack; seq=5712;rtptime=934207921, url=rtsp://example.com/fizzle/videotrack; seq=57654;rtptime=2792482193 The spec should make this clear. An interesting consideration to make here is a restriction on Range response. The current rtsp spec states that "The unit of the range in the reply is the same as that in the request". Perhaps an alternate syntax, if the PLAY request has a Range: header in npt is as follows: Range: npt=now;time=20021120T133205Z The "time" allows for mapping to occur. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-30 19:36 Message: Logged In: YES user_id=302620 Yes, the range header is need for RTP synchonization. The draft specification has been updated to require this when using RTP to make synchonization possible. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=619421&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 01:42:20 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-494533 ] The use of the word require in the RFC. Bugs item #494533, was opened at 2001-12-18 11:16 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494533&group_id=23194 >Category: Editorial Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: The use of the word require in the RFC. Initial Comment: The RFC contains different usage of the word require. Sometimes it means that a implementation must interpret and understand a header or method. Othertimes the a certain header must be sent togheter with a method. One fix is to create a better table for the headers that clarifies the two different cases. Another is looking over the methods and use cases and clearly write when they must be included. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 10:42 Message: Logged In: YES user_id=302620 There are also a great need to look at the usage of normative language according to RFC 2119. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-19 02:29 Message: Logged In: YES user_id=3796 We need to rework that table to clarify the difference between the two. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=494533&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: "SourceForge.net" Date: Thu, 23 Oct 2003 06:12:43 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-507882 ] RTP timestamps when playing after pause Bugs item #507882, was opened at 2002-01-24 09:30 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 Category: General Group: Resolved - Need write up Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Aravind Narasimhan (arvy_n) Summary: RTP timestamps when playing after pause Initial Comment: What happends to the RTP timestamp when you issue a play after being paused for some time? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 15:12 Message: Logged In: YES user_id=302620 Aravind has agreed to write up the example and necessary text. Transfering bug to him. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-09-22 10:48 Message: Logged In: YES user_id=302620 A Clear example of RTP Timestamp and synchronization will be added in appendix B - RTP transport. The discussion in MMUSIC has made it clear that a continous time model is needed to make RTCP work correctly. It has to be accpeted that for on-demand media this will result in slightly more code for the clients and servers. However all pices to makes things work is already present. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-05-23 16:05 Message: Logged In: YES user_id=302620 This has been further discussed in the MMUSIC mailing list. A important point is that RTP and RTCP to function as intended in this environment must have a timestamp space that increase continously with real time. A client handling the RTSP range header and RTP-Info can always synchronize the data correctly independtly of which case the server sent out. Using a continous RTP Timestamp space allows the same timestamp model for both on-demand and live media. The proposed resolution is to clrafiy in the RTP appendix of the specification that a RTP timestamp space continous in regards to real-time SHALL be used. Further write a warning that this has been missunderstood and clients is RECOMMENDED to handle both cases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=507882&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 07:32:52 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-625342 ] DESCRIBE Res needed in C.2 and C.3 Bugs item #625342, was opened at 2002-10-18 20:00 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194 >Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Go Hori (ghori) >Assigned to: Magnus Westerlund (magwes) Summary: DESCRIBE Res needed in C.2 and C.3 Initial Comment: In the examples for aggregate control SDP and subsequent SETUP request, it is confusing how a URL for SETUP is created. It is missing a DESCRIBE response and gives an impression that a sesseion level control string was used as a base URL. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 16:32 Message: Logged In: YES user_id=302620 I agree that the example was not clear. This has now been corrected by including a DESCRIBE response for the aggregated example which has defines a Content-Base, which is the most reasonable solution to this problem. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-10-31 13:24 Message: Logged In: YES user_id=302620 We may also want to define a dedault rule to create control URLs based on the first media setup so that sessions missing session level control URLs are still possible to set up in aggregates. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=625342&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: "SourceForge.net" Date: Fri, 24 Oct 2003 04:37:03 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-563153 ] Appendix C: agg/non-agg mixup Bugs item #563153, was opened at 2002-06-01 03:42 Message generated for change (Comment added) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 Category: General Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) >Assigned to: Magnus Westerlund (magwes) Summary: Appendix C: agg/non-agg mixup Initial Comment: The initial descriptions of aggregate and non-aggregate contol are reversed, and poorly written. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2003-10-24 13:37 Message: Logged In: YES user_id=302620 I have went over the SDP appendix once more and found some more strangeness regarding aggregated and non-aggregated. This is now fixed. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-06-06 22:24 Message: Logged In: YES user_id=3796 It turns out this had already been fixed in the draft-00 version. However, the wording was still very confusing. This has been fixed in the version checked into CVS. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/sdp.tex.diff?r1=1.3&r2=1.4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=563153&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Oct 26 14:54:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25638 for ; Sun, 26 Oct 2003 14:54:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADqxg-0007nI-36 for mmusic-archive@odin.ietf.org; Sun, 26 Oct 2003 14:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9QJs4hq029953 for mmusic-archive@odin.ietf.org; Sun, 26 Oct 2003 14:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADqxf-0007n2-Vk for mmusic-web-archive@optimus.ietf.org; Sun, 26 Oct 2003 14:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25627 for ; Sun, 26 Oct 2003 14:53:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADqxd-0000CP-00 for mmusic-web-archive@ietf.org; Sun, 26 Oct 2003 14:54:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ADqxc-0000CM-00 for mmusic-web-archive@ietf.org; Sun, 26 Oct 2003 14:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADqxc-0007mT-MH; Sun, 26 Oct 2003 14:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ADqx2-0007kh-3M for mmusic@optimus.ietf.org; Sun, 26 Oct 2003 14:53:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25604 for ; Sun, 26 Oct 2003 14:53:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ADqwz-0000C9-00 for mmusic@ietf.org; Sun, 26 Oct 2003 14:53:21 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ADqwy-0000Bl-00 for mmusic@ietf.org; Sun, 26 Oct 2003 14:53:20 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:60886 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ADqwU-0008D7-00; Sun, 26 Oct 2003 19:52:50 +0000 Date: Sun, 26 Oct 2003 19:52:48 +0000 Subject: Re: [MMUSIC] SDP b= clarification Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: mmusic@ietf.org To: Tom Marshall From: Colin Perkins In-Reply-To: <20031022202043.GF19150@real.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, Oct 22, 2003, at 21:20 Europe/London, Tom Marshall wrote: >>>> The ABNF in draft-ietf-mmusic-sdp-new-13.txt explicitly allows >>>> repetition. >>>> >>>> bandwidth-fields = *("b=" bwtype ":" bandwidth CRLF) >>>> bwtype = token >>>> bandwidth = 1*DIGIT >>> >>> Cool. Could we get a note in the text that corresponds with the >>> ABNF? >> >> Provided there are no objections, if you suggest explicit wording >> changes, I can incorporate them into -15. > > This would be the simplest change: > > --- draft-ietf-mmusic-sdp-new-14.txt 2003-10-22 > 12:51:26.000000000 -0700 > +++ draft-ietf-mmusic-sdp-new-14-edited.txt 2003-10-22 > 13:18:57.000000000 -0700 > @@ -495,7 +495,7 @@ > p=* (phone number) > c=* (connection information - not required if included in > all media) > - b=* (bandwidth information) > + b=* (zero or more bandwidth information lines) > One or more time descriptions (see below) > > > @@ -519,7 +519,7 @@ > i=* (media title) > c=* (connection information - optional if included at > session-level) > - b=* (bandwidth information) > + b=* (zero or more bandwidth information lines) > k=* (encryption key) > a=* (zero or more media attribute lines) Will be in -15 -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 01:46:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15373 for ; Mon, 27 Oct 2003 01:46:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE18e-0004nJ-Eb for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 01:46:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R6k4D3018428 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 01:46:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE18e-0004n6-8w for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 01:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15348 for ; Mon, 27 Oct 2003 01:45:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE18a-0007SC-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 01:46:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE18a-0007S8-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 01:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE18a-0004kx-S3; Mon, 27 Oct 2003 01:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE183-0004iA-Oy for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 01:45:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15311 for ; Mon, 27 Oct 2003 01:45:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE180-0007RH-00 for mmusic@ietf.org; Mon, 27 Oct 2003 01:45:24 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AE17z-0007Qt-00 for mmusic@ietf.org; Mon, 27 Oct 2003 01:45:23 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9R6inio082567; Sun, 26 Oct 2003 22:44:49 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Sun, 26 Oct 2003 22:44:49 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BF1@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , Thomas Zeng Cc: IETF MMUSIC WG , Greg Sherwood , David Kosiba Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Date: Sun, 26 Oct 2003 22:44:48 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Our use case is best handled by a feature-tag, I think. Let me clarify: even if "time=" is deprecated in Range header in the core spec, we can still "resurrect" it in a extension to RTSP protocol, as long as we address any ambuguity (I believe we can)? More embedded. thanks, thomas > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Wednesday, October 22, 2003 1:33 AM > To: Thomas Zeng > Cc: IETF MMUSIC WG > Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 > > > Hi Thomas, > > If you have a use cases for this, I think it is possible to keep the > timed functionality, under the condition that you provide all > necessary > specification text to solve the problems with timed PLAYs. We will either propose timed PLAY or timed PLAYLIST_PLAY. > > I would also like to have some more information about use case. > The use case involves server-side playlist play, where one may desire to have the option to jump to a new item in the playlist, but only at the end of the current item. > The big problem with the timed requests are the following: > > - Are they allowed to be stacked, are multiple possible to be > requested > for later execution? If yes, the real problems exist. No, only outstanding timed request is allowed. That is, the stack size is 1. > > - If you use timed requests how does the interaction happens with the > state machine. When are the state transition made, when the > request is > received or when it is executed. The first PLAY is always executed immediately. So state transition is no issue. In another words, timed PLAY is only in PLAYING state for clip transition. > > - How is errors at the time of execution handled? Error will be reported via event report (say via SET_PARAMETER or ANNOUNCE). > > - If multiple requests are allowed, how does one handle if > two request > collide. Again, only one timed request is allowed. > > - How do you stop a timed request, between acceptance and execution? > By sending another PLAY or PLAYLIST_PLAY. > These are probably not all the problems, simply the ones I > can remember > of the top of my head. > > So please provide a solution proposal so we can discuss and > review if it > solves the problems in a satisfactory way. > > cheers > > Magnus > > Thomas Zeng wrote: > > > Magnus: > > > > During one of the telecon for RTSP, I recall that a > decision was made to > > deprecate "time=" parameter in Range header. > > > > We have found a use case in the context of playlist > support, where we would > > like to use > > "time=" parameter in Range header in the PLAY request as designed in > > RFC2326, quoted below: > > > > 10.5 PLAY > > > > ... > > > > The Range header may also contain a time parameter. This > parameter > > specifies a time in UTC at which the playback should > start. If the > > message is received after the specified time, playback is started > > immediately. The time parameter may be used to aid in > synchronization > > of streams obtained from different sources. > > > > > > > > In light of this, would it be possible to retain this "time > parameter"? > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 04:00:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02035 for ; Mon, 27 Oct 2003 04:00:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3EM-0000dc-K7 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 04:00:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R906Eo002440 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 04:00:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3EK-0000d8-Ly for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 04:00:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02002 for ; Mon, 27 Oct 2003 03:59:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3EH-0001MM-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 04:00:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE3EH-0001MJ-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 04:00:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3EI-0000cE-7N; Mon, 27 Oct 2003 04:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3ED-0000b5-9k for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 03:59:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01993 for ; Mon, 27 Oct 2003 03:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3EA-0001M2-00 for mmusic@ietf.org; Mon, 27 Oct 2003 03:59:54 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AE3E9-0001Lz-00 for mmusic@ietf.org; Mon, 27 Oct 2003 03:59:54 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9R8xsSs020600; Mon, 27 Oct 2003 09:59:54 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VWW65J9Q; Mon, 27 Oct 2003 09:59:54 +0100 Message-ID: <3F9CDE7C.8000408@ericsson.com> Date: Mon, 27 Oct 2003 09:59:40 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Zeng CC: IETF MMUSIC WG , Greg Sherwood , David Kosiba Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 References: <72263E8E8622D611975C0002B32C19D805A17BF1@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17BF1@misty.packetvideo.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 Thomas, I don't think there will be any problem with later writing a extension draft resolving the problems and how one likes this to work. Through the use of a feature tag and a the Require header the client can ensure that the server interprets the timed field correctly in such requests. Please note that I am not removing the syntactical element, rather declaring it as shall not be used in the core spec for other purposes then REDIRECT. I hope you look over the possible solutions for playlist to find what is a good solution. If one take the simple approach only having the desire to delay the start of the playback the problems would not be to hard to solve. However it would be simpler if one haves a separate extension draft for this rather than using the core specification, which I interprets as being your intention. Cheers Magnus Thomas Zeng wrote: > Magnus: > > Our use case is best handled by a feature-tag, I think. Let me clarify: > even if "time=" is deprecated > in Range header in the core spec, we can still "resurrect" it in a extension > to RTSP protocol, as long as > we address any ambuguity (I believe we can)? > > More embedded. > > thanks, > thomas > > >>-----Original Message----- >>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>Sent: Wednesday, October 22, 2003 1:33 AM >>To: Thomas Zeng >>Cc: IETF MMUSIC WG >>Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 >> >> >>Hi Thomas, >> >>If you have a use cases for this, I think it is possible to keep the >>timed functionality, under the condition that you provide all >>necessary >>specification text to solve the problems with timed PLAYs. > > > We will either propose timed PLAY or timed PLAYLIST_PLAY. > >>I would also like to have some more information about use case. >> > > The use case involves server-side playlist play, where one may desire to > have the option to jump to a new > item in the playlist, but only at the end of the current item. > >>The big problem with the timed requests are the following: >> >>- Are they allowed to be stacked, are multiple possible to be >>requested >>for later execution? If yes, the real problems exist. > > > No, only outstanding timed request is allowed. That is, the stack size is 1. > >>- If you use timed requests how does the interaction happens with the >>state machine. When are the state transition made, when the >>request is >>received or when it is executed. > > > The first PLAY is always executed immediately. So state transition is no > issue. > In another words, timed PLAY is only in PLAYING state for clip transition. > >>- How is errors at the time of execution handled? > > Error will be reported via event report (say via SET_PARAMETER or ANNOUNCE). > >>- If multiple requests are allowed, how does one handle if >>two request >>collide. > > > Again, only one timed request is allowed. > >>- How do you stop a timed request, between acceptance and execution? >> > > By sending another PLAY or PLAYLIST_PLAY. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 04:46:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03844 for ; Mon, 27 Oct 2003 04:46:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3wr-0004vY-Dk for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 04:46:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9R9k5Hd018934 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 04:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3wr-0004vJ-7Y for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 04:46:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03794 for ; Mon, 27 Oct 2003 04:45:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3wo-000218-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 04:46:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE3wn-000215-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 04:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3wo-0004u9-EX; Mon, 27 Oct 2003 04:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE3wk-0004tT-Bk for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 04:45:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03781 for ; Mon, 27 Oct 2003 04:45:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE3wh-00020q-00 for mmusic@ietf.org; Mon, 27 Oct 2003 04:45:55 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AE3wg-00020n-00 for mmusic@ietf.org; Mon, 27 Oct 2003 04:45:54 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9R9jsI2027889; Mon, 27 Oct 2003 10:45:54 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VWXB7LX5; Mon, 27 Oct 2003 10:45:54 +0100 Message-ID: <3F9CE944.6040903@ericsson.com> Date: Mon, 27 Oct 2003 10:45:40 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Marshall CC: Matthew Heaney , mmusic@ietf.org, zeng@PacketVideo.COM Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream References: <20031024195521.GH13908@real.com> In-Reply-To: <20031024195521.GH13908@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, You having this discussion on a friday evening (my time) makes it kind of hard of give comments into the discussion :-). So I guess it falls on my lot to summarize and give comments on what I see as important considerations. There are several possible solutions that all have advantages and drawbacks. 1. Using RTCP BYE - bye sending a RTCP bye the server will signal that it is leaving the session with the indicated SSRC(s). As this is probably not the intended effect in many cases RTCP bye is not semantically correct. - Killing the SSRC prevents the continues reporting of RTCP sender reports allowing a client not supporting the end of stream mechanism to detect that it is lost. - The intention of RTCP BYE is to work as hint to help keeping the accurate group size, therefore it is not very robust. RTCP bye are only sent once and any receiver not getting it will time-out the source instead. Personal comment: I am not in favour of using this mechanism. 2. Using an RTCP extension, APP or other - By including SSRC and RTP sequence number of the last packet to be sent the server the RTCP packet can be sent both earlier and later than the transmission of the last RTP packet. - Requires the usage of RTCP, which in my opinion in most cases is good. I know there might be use cases where RTCP may not be possible to use even from server to client(s). - RTCP is not robust, message will be need to be repeated. Due to RTCP bandwidth limitation this might result in that it takes some time to get the message across. 3. Using the RTSP signalling channel with an END_OF_STREAM method. - Sent in the RTSP signalling channel, so if TCP is used it is robust. Will get the message over as soon as TCP can transmit it. However due to packet losses this time is not bound, it might still arrive late. - Is not RTP specific, through the usage of other transport protocols equivalent to RTP-Info they could inform what the last packet that belongs to the request is. - Due to the use of RTSP signalling channel it may go through one or more proxies. Thus taking longer time than the media path. - If the client drops the signalling connection it will not be possible to get over. - One message will cover all streams in the same RTSP session. 4. Use a RTP extension. This solution can either be implemented through a new RTP payload format including the necessary information, or through some RTP header extension. - Will go in the media channel as media rather than signalling. - Can't be sent in advance for certain media requiring continuos RTP sequence numbers if it requires its own packets. - Is not robust will require that one either uses some type of ACKs and adaptive transmission of them or do a repetition accomplishing high enough delivery probability. - The use of header extension would prevent other header extensions. - The use of a payload format would either require its own RTP packet or use of RFC 2198. General comments: - Please note that any end of stream indication will not be 100% reliable and guaranteed to arrive in time before the last packet arrives. - Regarding messages from server to client. The client are not required to keep the TCP connection open, however it is strongly recommended. My intention with the current text around connections is that the protocol shall survive the loss of the signalling channel. That this allows for clients to close the TCP connection has to be accepted. - Regarding the requirement about state transition as an indication. This is not suitable in all use cases. I think this mechanism if located in RTP/RTCP then it should work also for multicast. Thus one needs to look into the separate use cases. I think we should further explore the pro and cons of proposal 2 to 4. Thus trying to decide what the desired solution is. There are probably further considerations that I have not yet thought of. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 05:53:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05959 for ; Mon, 27 Oct 2003 05:53:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4zg-0002wo-PK for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 05:53:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RAr4dS011329 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 05:53:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4zg-0002we-Lg for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 05:53:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05922 for ; Mon, 27 Oct 2003 05:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4zc-0002kD-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 05:53:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE4zc-0002kA-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 05:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4zd-0002u4-VZ; Mon, 27 Oct 2003 05:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE4yy-0002qW-1w for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 05:52:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05899; Mon, 27 Oct 2003 05:52:06 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE4yt-0002jS-00; Mon, 27 Oct 2003 05:52:15 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AE4yt-0002jO-00; Mon, 27 Oct 2003 05:52:15 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id h9RAqFI18901; Mon, 27 Oct 2003 12:52:15 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 27 Oct 2003 12:51:57 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 12:51:57 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 27 Oct 2003 12:51:56 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 27 Oct 2003 12:51:53 +0200 Message-ID: Thread-Topic: [AVT] AVT Charter update Thread-Index: AcNxVxTqZ8KLcjOBQ5KJUz7nS+NoXwAudvqA To: , Cc: , , X-OriginalArrivalTime: 27 Oct 2003 10:51:56.0933 (UTC) FILETIME=[5730CB50:01C39C78] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] time-lined static media with FLUTE & IMG Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Magnus, Ross (and everyone) 1=BD-2 years back there was a draft on time-lined static media = (draft-westerlund-avt-rtp-static-media-01) - basically to send files, = text (etc) with timed presentation along with AV media streams. Since = the basic requirements haven't gone away, but RMT has made progress on = usable protocols, what do you think about using FLUTE = (draft-ietf-rmt-flute-02) for the same job? With a quick comparison I = think it should be pretty straight forward, although you may have some = preferences (or extensions to the FLUTE-FDT) if you already have a = working RTP-payload'ed implementation. Ross mentioned sending ID-3 tags in-band with audio streams. Any ideas = you have on doing this with FLUTE (ID3) and RTP (music) could be pretty = useful for the Internet Media Guide (IMG) work in MMUSIC - how to move = around (and announce) metadata for 'foo' multicast and unicast sessions. Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 07:28:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09445 for ; Mon, 27 Oct 2003 07:28:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Tb-0004IA-1A for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 07:28:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RCS2SB016492 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 07:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6Ta-0004Hv-Sx for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 07:28:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09439 for ; Mon, 27 Oct 2003 07:27:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6Ta-00045l-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 07:28:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE6TZ-00045i-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 07:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6TZ-0004HC-I2; Mon, 27 Oct 2003 07:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE6TX-0004Gm-C9 for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 07:27:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09436 for ; Mon, 27 Oct 2003 07:27:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE6TW-00045f-00 for mmusic@ietf.org; Mon, 27 Oct 2003 07:27:58 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AE6TV-00045Z-00 for mmusic@ietf.org; Mon, 27 Oct 2003 07:27:57 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:62007 helo=csperkins.org) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AE6T0-0002Ed-00 for mmusic@ietf.org; Mon, 27 Oct 2003 12:27:26 +0000 Date: Mon, 27 Oct 2003 12:27:23 +0000 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: multipart/mixed; boundary=Apple-Mail-8-903613865 From: Colin Perkins To: mmusic@ietf.org Message-Id: X-Mailer: Apple Mail (2.552) Subject: [MMUSIC] draft-ietf-mmusic-sdp-new-15.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: , --Apple-Mail-8-903613865 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit I've just submitted draft-ietf-mmusic-sdp-new-15.txt to address IESG concerns and other comments raised on the mailing list. Changes since -14 include: - Update references: RFC 1889 -> RFC 3550 RFC 1890 -> RFC 3551 draft-ietf-mmusic-sdp4nat-05.txt -> RFC 3605 - Clarify that b= may be duplicated - Clarify that multiple addresses or "c=" lines can only be specified if they provide multicast addresses for different layers - Clarify use of b= with layered coding: When using the CT modifier with RTP, if several RTP sessions are part of the conference, the conference total refers to total bandwidth of all RTP sessions. - Clarify which ports are associated with an m= line when layered coding is used - Remove extra ")" from the definition of m1 in the ABNF - Add reference to RFC2396 in definition of u= - Add MIME registration to the IANA Considerations section, and note that this draft updates RFC 2327 - In the description of "k=", note that S/MIME email and TLS protected HTTP and SIP might be appropriate secure transports for SDP. Also note that it is necessary to "ensure that the secure channel is with the party that is authorized to join the session, not an intermediary" and "If a caching server is used, there ought to be a way to keep the server from accessing the key" - The recommendation that systems "SHOULD NOT deliver the user into an interactive multimedia session without the user being aware that this will happen" in the Security Considerations section was strengthened to "MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorized such action" - A comment in the ABNF for "token-char" allowed a larger set of characters than the actual definition. The comment has been removed, leaving the set of allowed characters as specified in the ABNF - Clarify that UTF-8 normalization is not needed because comparisons are not done on fields with UTF-8. - Clarify that k= is NOT RECOMMENDED and give pointers to the sdescriptions and key-mgmt drafts. - Clarify that k= does not include an algorithm identifier, key type, or any other information about the key. - Clarify that k= does not support the transfer of two keys - Remove reference to RFC 3551/1890 from the description of k=, since that nowhere specified how k= was used. - Note that a session description may contain URIs which may be dereferenced. This makes the SDP non-self contained. - Remove "Changes from RFC 2327" section, since it was very inaccurate and outdated. Feedback on these changes would be appreciated. -- Colin Perkins http://csperkins.org/ --Apple-Mail-8-903613865 Content-Disposition: attachment; filename=14-15.diff Content-Type: application/octet-stream; x-unix-mode=0660; name="14-15.diff" Content-Transfer-Encoding: 7bit --- sdp-14.xml Fri Sep 5 12:45:27 2003 +++ sdp.xml Mon Oct 27 12:21:58 2003 @@ -1,10 +1,11 @@ + + docName="draft-ietf-mmusic-sdp-new-15.txt"> SDP: Session Description Protocol @@ -44,7 +45,7 @@ csp@csperkins.org - + This memo defines the Session Description Protocol (SDP). SDP is @@ -58,6 +59,9 @@
+ [Note to RFC Editor: All references to RFC XXXX should be replaced by + the RFC number of this document, when published.] + When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other real-time sessions, there is a requirement to convey media details, transport addresses, and other session @@ -67,10 +71,11 @@ irrespective of how that information is transported. SDP is purely a format for session description - it does not incorporate a transport protocol, and is intended to use different transport protocols as - appropriate, including the Session Announcement Protocol [RFC2974], - Session Initiation Protocol [RFC3261], Real-Time Streaming Protocol - [RFC2326], electronic mail using the MIME extensions, and the Hypertext - Transport Protocol. + appropriate, including the Session Announcement Protocol + , Session Initiation Protocol + , Real-Time Streaming Protocol + , electronic mail using the MIME extensions, + and the Hypertext Transport Protocol. SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not @@ -104,7 +109,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + document are to be interpreted as described in + RFC 2119.
@@ -122,23 +128,23 @@ required to participate in the session. One protocol commonly used to implement such a distributed directory - is the Session Announcement Protocol, SAP [RFC2974]. SDP provides + is the Session Announcement Protocol, SAP. SDP provides the recommended session description format for such announcements.
- The Session Initiation Protocol, SIP [RFC3261] is an application layer + The Session Initiation Protocol, SIP is an application layer control protocol for creating, modifying and terminating sessions such as Internet multimedia conferences, Internet telephone calls and multimedia distribution. The SIP messages used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. These session descriptions are commonly - formatted using SDP. When used with SIP, the offer/answer model - [RFC3264] provides a limited framework for negotiation using SDP. + formatted using SDP. When used with SIP, the + offer/answer model provides a limited framework for negotiation using SDP.
- The Real Time Streaming Protocol, RTSP [RFC2326], is an application- + The Real Time Streaming Protocol, RTSP, is an application- level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and @@ -250,7 +256,8 @@ typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP - e.g. mechanisms are - defined for SDP transported using SAP [RFC2974] and SIP [RFC3261]. + defined for SDP transported using SAP + and SIP. If a session announcement is private it is possible to use that private announcement to convey encryption keys necessary to decode @@ -275,7 +282,7 @@
The SDP specification recommends the use of the ISO 10646 character - sets in the UTF-8 encoding [RFC2279] to allow many different languages + sets in the UTF-8 encoding to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalization only applies to free-text fields @@ -290,7 +297,9 @@ SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual fields and - attribute values MAY use the full ISO 10646 character set. The + attribute values MAY use the full ISO 10646 character set. Field and + attribute values which use the full UTF-8 character set are never directly + compared, hence there is no requirement for UTF-8 normalization. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used (e.g, session description in a MIME email message) and to @@ -306,6 +315,11 @@ discarded. This also allows rapid discarding of encrypted announcements for which a receiver does not have the correct key. + An SDP session description may contain URIs which reference + external content in the "u=", "k=" and "a=" lines. These URIs may be + dereferenced in some cases, making the session description non-self + contained. + An SDP session description consists of a number of lines of text of the form: @@ -346,7 +360,7 @@ p=* (phone number) c=* (connection information - not required if included in all media) - b=* (bandwidth information) + b=* (zero or more bandwidth information lines) One or more time descriptions (see below) z=* (time zone adjustments) k=* (encryption key) @@ -362,7 +376,7 @@ i=* (media title) c=* (connection information - optional if included at session-level) - b=* (bandwidth information) + b=* (zero or more bandwidth information lines) k=* (encryption key) a=* (zero or more media attribute lines) @@ -442,7 +456,7 @@ type> and <address> form a globally unique identifier for the session. The method of session id allocation is up to the creating tool, but it has been suggested that a Network Time Protocol (NTP) - format timestamp be used to ensure uniqueness [RFC1305]. + format timestamp be used to ensure uniqueness . is a version number for this announcement. It is needed for proxy announcements to detect which of several @@ -526,7 +540,8 @@ - A URI is a Universal Resource Identifier as used by WWW clients. + A URI is a Universal Resource Identifier as used by WWW clients + . The URI should be a pointer to additional information about the conference. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI @@ -715,8 +730,9 @@ Multiple addresses or "c=" lines MAY be specified on a per-media - basis. They MUST NOT be specified for a session-level "c=" field. - + basis only if they provide multicast addresses for different layers + in a hierarchical or layered encoding scheme. They MUST NOT be + specified for a session-level "c=" field. The slash notation described above MUST NOT be used for IP unicast addresses. @@ -737,29 +753,30 @@ modifiers defined in this memo use the default units). The <modifier> is a single alphanumeric word giving the meaning - of the bandwidth figure. Two modifiers are initially defined: + of the bandwidth figure. Two modifiers are initially defined: -
- - CT Conference Total + + If the bandwidth of a session or media in a session is different from the bandwidth implicit from the scope, a "b=CT:..." line should be supplied for the session giving the proposed upper limit to the bandwidth used. The primary purpose of this is to give an approximate idea as to whether - two or more sessions can co-exist simultaneously. + two or more sessions can co-exist simultaneously. When using + the CT modifier with RTP, if several RTP sessions are part of + the conference, the conference total refers to total bandwidth + of all RTP sessions. - AS Application-Specific Maximum + The bandwidth is interpreted to be application-specific (it will be the application's concept of maximum bandwidth). Normally this will coincide with what is set on the application's "maximum bandwidth" control if applicable. For RTP based applications, AS gives the RTP "session - bandwidth" as defined in section 6.2 of [RFC1889]. - -
+ bandwidth" as defined in section 6.2 of . + - Note that CT gives a total bandwidth figure for all the media at + Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously. @@ -798,7 +815,7 @@ The first and second sub-fields give the start and stop times for the session respectively. These values are the decimal representation - of Network Time Protocol (NTP) time values in seconds [RFC1305]. + of Network Time Protocol (NTP) time values in seconds . To convert these values to UNIX time, subtract decimal 2208988800. @@ -941,13 +958,28 @@ If transported over a secure and trusted channel, the session - description protocol MAY be used to convey encryption keys. A key - field is permitted before the first media entry (in which case it - applies to all media in the session), or for each media entry as - required. - - The format of keys and their usage is outside the scope of this - document, but see [RFC1890] for an example. + description protocol MAY be used to convey encryption keys. A + simple mechanism for key exchange is provided by the key field + ("k=") although this is primarily supported for compatibility + with older implementations and its use is NOT RECOMMENDED. Work + is in progress to define new key exchange mechanisms for use + with SDP + + + and it is expected that new applications will use those mechanisms. + + + A key field is permitted before the first media entry (in which + case it applies to all media in the session), or for each media + entry as required. The format of keys and their usage is outside + the scope of this document, and the key field provides no way to + indicate the encryption algorithm to be used, key type, or other + information about the key: this is assumed to be provided by the + higher-level protocol using SDP. If there is a need to convey this + information within SDP, the extensions mentioned previously SHOULD + be used. Many security protocols require two keys, one for + confidentiality and another for integrity. This specification does + not support the transfer of two keys. The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. @@ -972,9 +1004,10 @@ A Universal Resource Identifier is included in the key field. The URI refers to the data containing the key, and may require - additional authentication before the key can be returned. When - a request is made to the given URI, the MIME content-type of - the reply specifies the encoding for the key in the reply. + additional authentication before the key can be returned. When + a request is made to the given URI, the reply should specify + the encoding for the key. The URI is often a secure HTTP URI, + although this is not required. k=prompt @@ -990,8 +1023,14 @@ The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example - of such a channel might be SDP embedded inside an S/MIME message. - + of such a channel might be SDP embedded inside an S/MIME message + or a TLS protected HTTP or SIP session. It is important to ensure + that the secure channel is with the party that is authorized to + join the session, not an intermediary: if a caching proxy server is + used, it is important to ensure that the proxy is either trusted or + unable to access the SDP. Definition of appropriate security measures + is beyond the scope of this specification, and should be defined by + the users of SDP.
@@ -1080,9 +1119,9 @@ network being used as specified in the relevant "c=" field, and on the transport protocol defined in the third sub-field. Other ports used by the media application (such as the RTCP port - [RFC1889]) MAY be derived algorithmically from the base media port + ) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (e.g. "a=rtcp:" as - defined in [RTCPSDP]). + defined in ). For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple @@ -1097,8 +1136,9 @@ In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even numbered ports are used - for data and the corresponding one-higher odd port is used for - RTCP. For example: + for data with the corresponding one-higher odd ports used for the + RTCP belonging to the RTP session, and the <number of ports> + denoting the number of RTP sessions. For example:
@@ -1110,7 +1150,7 @@ and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the transport protocol and 31 is the format (see below). If non- contiguous ports are required, they must be signalled using a - separate attribute (e.g. "a=rtcp:" as defined in [RTCPSDP]). + separate attribute (e.g. "a=rtcp:" as defined in ). If multiple addresses are specified in the "c=" field and multiple ports are specified in the "m=" field, a one-to-one mapping from @@ -1162,8 +1202,8 @@ RTP PCM audio. In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. - For RTP media streams operating under the RTP Audio/Video Profile - [RFC1890], the protocol field is "RTP/AVP". Should other RTP + For RTP media streams operating under the RTP + Audio/Video Profile, the protocol field is "RTP/AVP". Should other RTP profiles be defined in the future, their profiles will be specified in the same way. For example, the protocol field "RTP/XYZ" would specify RTP operating under a profile whose short @@ -1258,7 +1298,7 @@ defined in the RTP Audio/Video Profile) packetisation is required, the "ptime" attribute is used as given below. - For more details on RTP audio and video formats, see [RFC1890]. + For more details on RTP audio and video formats, see . Predefined application formats for the UDP protocol with non-RTP media are as below: @@ -1393,7 +1433,7 @@ Specifying the attribute "type:H332" indicates that this loosely coupled session is part of a H.332 session as defined - in the ITU H.332 specification [H.332]. Media tools should be + in the ITU H.332 specification [15]. Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint @@ -1452,7 +1492,7 @@ allowed although NOT RECOMMENDED. The "sdplang" attribute value must be a single RFC 3066 - language tag in US-ASCII [RFC3066]. It is not dependent on + language tag in US-ASCII [6]. It is not dependent on the charset attribute. An "sdplang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot @@ -1473,7 +1513,7 @@ session or media from most important to least important. The "lang" attribute value must be a single RFC 3066 language - tag in US-ASCII [RFC3066]. It is not dependent on the charset + tag in US-ASCII [6]. It is not dependent on the charset attribute. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of recipients cannot be assumed, or where @@ -1602,9 +1642,9 @@ appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving their consent. Thus a session description arriving by session - announcement, email, session invitation, or WWW page SHOULD NOT - deliver the user into an interactive multimedia session without the - user being aware that this will happen. As it is not always simple + announcement, email, session invitation, or WWW page MUST NOT + deliver the user into an interactive multimedia session unless the + user has explicitly pre-authorized such action. As it is not always simple to tell whether a session is interactive or not, applications that are unsure should assume sessions are interactive. @@ -1636,6 +1676,61 @@
+
+ + One new MIME type is to be registered, as defined below. This updates + the previous definition from RFC 2327. + +
+ + + To: ietf-types@iana.org + Subject: Registration of MIME media type application/sdp + + MIME media type name: application + + MIME subtype name: sdp + + Required parameters: None. + + Optional parameters: None. + + Encoding considerations: + See section 5 of RFC XXXX + + Security considerations: + See section 8 of RFC XXXX + + Interoperability considerations: + See RFC XXXX + + Published specification: + RFC XXXX + + Applications which use this media type: + Voice over IP, video teleconferencing, streaming media, instant + messaging, etc. See also section 3 of RFC XXXX. + + Additional information: + + Magic number(s): None. + File extension(s): The extension ".sdp" is commonly used. + Macintosh File Type Code(s): + + Person & email address to contact for further information: + Colin Perkins <csp@csperkins.org> + IETF MMUSIC working group + + Intended usage: COMMON + + Author/Change controller: + Authors of RFC XXXX + IETF MMUSIC working group + + +
+
+
There are seven field names that may be registered with IANA. Using the terminology in the SDP specification BNF, they are "media", @@ -1651,16 +1746,16 @@ a standards-track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the - "Standards Action" policy of RFC 2434 [RFC2434]). + "Standards Action" policy of RFC 2434.
The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo - registers three values: "RTP/AVP" is a reference to RTP [RFC1889] - used under the RTP Profile for Audio and Video Conferences with - Minimal Control [RFC1890]) running over UDP/IP; "TCP" denotes an + registers three values: "RTP/AVP" is a reference to RTP + used under the RTP Profile for Audio and Video Conferences with + Minimal Control running over UDP/IP; "TCP" denotes an unspecified format over TCP; and "udp" indicates an unspecified format over UDP. @@ -1804,11 +1899,12 @@ will be made.
+
This appendix provides an Augmented BNF grammar for SDP. ABNF is - defined in [RFC2234]. + defined in .
@,;: token = 1*(token-char) @@ -2064,70 +2156,6 @@
- - - - - Deprecate X- notation for experimental parameters - - Clarify that a=recvonly does NOT mean that you don't send RTCP, and - similarly for sendonly and inactive. These only effect the RTP stream. - - Rewrite and correct the ABNF syntax (thanks to Jonathan Lennox) - - Update BNF to support IPv6. - - Add a=inactive attribute. - - Add a=maxptime attribute. - - RFC 2327 mandated that either e= or p= was required. Both are now - optional, to reflect actual usage. - - Removed references to "conference" from the description of the t= line, - to make it less SAP oriented. - - Note about wrap-around of NTP timestamps in t= - - References have been updated and split into normative and informative - sections. - - Section 3.1 was replaced with a reference to RFC 2119, and the memo has - been updated to use the RFC 2119 terminology (MUST, SHOULD, etc). - - Use of "application/sdp" as MIME a type for SDP files is now "MUST" - rather than "SHOULD". - - Many sections have been updated to be less SAP specific, and to reference - other current uses of SDP such as RTSP and SIP. - - The introduction and background has been rewritten, to remove references - to the Mbone, reflecting current use of SDP. - - The section on concatenation of session descriptions (which was not - allowed in SAP, but allowed in other cases) has been removed. It is - assumed that transports of SDP specify will specify this. - - The description of the c= line has been updated to reflect common usage - of SDP, rather than Mbone conferencing with SAP. - - The b= line no longer makes a normative reference to the Mbone FAQ for - bandwidth limits at various TTLs. The AS modifier to b= is noted as - being the RTP session bandwidth. - - Define relation between the m= line and MIME types - - Note use of s= in sessions with no meaningful name - - Allow a=rtpmap to be a session level attribute, in addition to a media - level attribute - - Clarify the limitations of the k= field - - Clarify IANA considerations - - - Many people in the IETF MMUSIC working group have made comments and @@ -2144,20 +2172,24 @@ + - - - - + + + + + + + --Apple-Mail-8-903613865-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 09:19:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14717 for ; Mon, 27 Oct 2003 09:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8D2-0006Gm-CS for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 09:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9REJ4gQ024094 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 09:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8D2-0006GX-8a for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 09:19:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14583 for ; Mon, 27 Oct 2003 09:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AE8D0-0005WT-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 09:19:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AE8Cz-0005WQ-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 09:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8Cz-0006FR-SR; Mon, 27 Oct 2003 09:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AE8CP-0006AN-KD for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 09:18:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14419; Mon, 27 Oct 2003 09:18:13 -0500 (EST) Message-Id: <200310271418.JAA14419@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: Mon, 27 Oct 2003 09:18:13 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Security Descriptions for Media Streams Author(s) : F. Andreasen, M. Baugher, D. Wing Filename : draft-ietf-mmusic-sdescriptions-02.txt Pages : 36 Date : 2003-10-24 This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdescriptions-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-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-10-24160808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-24160808.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 11:19:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23099 for ; Mon, 27 Oct 2003 11:19:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA59-0003eD-3o for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 11:19:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RGJ3D6014017 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 11:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA59-0003e0-0b for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 11:19:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23079 for ; Mon, 27 Oct 2003 11:18:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEA58-0007Ye-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 11:19:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEA57-0007Yb-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 11:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA57-0003dU-3h; Mon, 27 Oct 2003 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEA4D-0003YC-N9 for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 11:18:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23019 for ; Mon, 27 Oct 2003 11:17:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEA4C-0007Xa-00 for mmusic@ietf.org; Mon, 27 Oct 2003 11:18:04 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEA4B-0007WY-00 for mmusic@ietf.org; Mon, 27 Oct 2003 11:18:04 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by manatick with esmtp (Exim 4.24) id 1AE9px-0003DR-0j for mmusic@ietf.org; Mon, 27 Oct 2003 11:03:21 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9RG2eio098142; Mon, 27 Oct 2003 08:02:40 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 08:02:40 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BF2@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , Thomas Zeng Cc: IETF MMUSIC WG , Greg Sherwood , David Kosiba Subject: RE: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 Date: Mon, 27 Oct 2003 08:02:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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@ericsson.com] > Sent: Monday, October 27, 2003 1:00 AM > To: Thomas Zeng > Cc: IETF MMUSIC WG; Greg Sherwood; David Kosiba > Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 > > > Hi Thomas, > > I don't think there will be any problem with later writing a > extension > draft resolving the problems and how one likes this to work. > Through the > use of a feature tag and a the Require header the client can > ensure that > the server interprets the timed field correctly in such > requests. Please > note that I am not removing the syntactical element, rather > declaring it > as shall not be used in the core spec for other purposes then > REDIRECT. > > I hope you look over the possible solutions for playlist to > find what is > a good solution. > > If one take the simple approach only having the desire to delay the > start of the playback the problems would not be to hard to solve. > However it would be simpler if one haves a separate extension > draft for > this rather than using the core specification, which I interprets as > being your intention. Yes, indeed. > > Cheers > > Magnus > > > Thomas Zeng wrote: > > > Magnus: > > > > Our use case is best handled by a feature-tag, I think. > Let me clarify: > > even if "time=" is deprecated > > in Range header in the core spec, we can still "resurrect" > it in a extension > > to RTSP protocol, as long as > > we address any ambuguity (I believe we can)? > > > > More embedded. > > > > thanks, > > thomas > > > > > >>-----Original Message----- > >>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > >>Sent: Wednesday, October 22, 2003 1:33 AM > >>To: Thomas Zeng > >>Cc: IETF MMUSIC WG > >>Subject: Re: [MMUSIC] RTSP: Minutes telecon 14th of October 2003 > >> > >> > >>Hi Thomas, > >> > >>If you have a use cases for this, I think it is possible to > keep the > >>timed functionality, under the condition that you provide all > >>necessary > >>specification text to solve the problems with timed PLAYs. > > > > > > We will either propose timed PLAY or timed PLAYLIST_PLAY. > > > >>I would also like to have some more information about use case. > >> > > > > The use case involves server-side playlist play, where one > may desire to > > have the option to jump to a new > > item in the playlist, but only at the end of the current item. > > > >>The big problem with the timed requests are the following: > >> > >>- Are they allowed to be stacked, are multiple possible to be > >>requested > >>for later execution? If yes, the real problems exist. > > > > > > No, only outstanding timed request is allowed. That is, the > stack size is 1. > > > >>- If you use timed requests how does the interaction > happens with the > >>state machine. When are the state transition made, when the > >>request is > >>received or when it is executed. > > > > > > The first PLAY is always executed immediately. So state > transition is no > > issue. > > In another words, timed PLAY is only in PLAYING state for > clip transition. > > > >>- How is errors at the time of execution handled? > > > > Error will be reported via event report (say via > SET_PARAMETER or ANNOUNCE). > > > >>- If multiple requests are allowed, how does one handle if > >>two request > >>collide. > > > > > > Again, only one timed request is allowed. > > > >>- How do you stop a timed request, between acceptance and execution? > >> > > > > By sending another PLAY or PLAYLIST_PLAY. > > > > > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 12:39:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26954 for ; Mon, 27 Oct 2003 12:39:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEBKZ-0003F2-W3 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 12:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RHd308012457 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 12:39:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEBKZ-0003Eq-Qo for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 12:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26933 for ; Mon, 27 Oct 2003 12:38:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBKY-000115-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 12:39:02 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEBKX-000112-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 12:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEBKW-0003EE-QE; Mon, 27 Oct 2003 12:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEBKH-0003D5-OE for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 12:38:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26924 for ; Mon, 27 Oct 2003 12:38:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEBKG-00010m-00 for mmusic@ietf.org; Mon, 27 Oct 2003 12:38:44 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AEBKF-00010j-00 for mmusic@ietf.org; Mon, 27 Oct 2003 12:38:43 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Mon, 27 Oct 2003 12:37:25 -0500 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Thread-Index: AcOcbzMTe31BP+h3SBOlH2InDnNXeAAQYDNg From: "Matthew Heaney" To: "Magnus Westerlund" , "Tom Marshall" Cc: , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Monday, October 27, 2003 4:46 AM > To: Tom Marshall >=20 > 4. Use a RTP extension. > This solution can either be implemented through a new RTP=20 > payload format=20 > including the necessary information, or through some RTP=20 > header extension. > - Will go in the media channel as media rather than signalling. > - Can't be sent in advance for certain media requiring continuos RTP=20 > sequence numbers if it requires its own packets. > - Is not robust will require that one either uses some type=20 > of ACKs and=20 > adaptive transmission of them or do a repetition accomplishing high=20 > enough delivery probability. > - The use of header extension would prevent other header extensions. > - The use of a payload format would either require its own=20 > RTP packet or=20 > use of RFC 2198. Other issues: o What is the rtp timestamp of the EOS indication? o If the EOS indication increments (rtp timestamps are "monotonically increasing"), then by how much should the timestamp increment for each EOS sent? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 14:20:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01507 for ; Mon, 27 Oct 2003 14:20:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECuM-0005XI-NL for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 14:20:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RJK62M021280 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 14:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECuM-0005X9-9U for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 14:20:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01457 for ; Mon, 27 Oct 2003 14:19:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECuJ-0002SH-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 14:20:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AECuJ-0002SE-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 14:20:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECuK-0005Wi-8D; Mon, 27 Oct 2003 14:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECts-0005VI-KH for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 14:19:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01454 for ; Mon, 27 Oct 2003 14:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECtq-0002S4-00 for mmusic@ietf.org; Mon, 27 Oct 2003 14:19:34 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AECtp-0002S1-00 for mmusic@ietf.org; Mon, 27 Oct 2003 14:19:33 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Mon, 27 Oct 2003 14:19:02 -0500 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Thread-Index: AcOcbzMTe31BP+h3SBOlH2InDnNXeAAQYDNgAANumYA= From: "Matthew Heaney" To: "Matthew Heaney" , "Magnus Westerlund" , "Tom Marshall" Cc: , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I suppose I should also bring up the issue of end-of-stream vs. end-of-play. =20 Perhaps it would be useful for the server to indicate that it's done playing all the streams implied by the aggregate play request. (This actually requires some work in the TrueCast case, since each stream is more or less independent. Right now I leave it up to the client to decide when to issue the (aggregate) PAUSE or TEARDOWN request following receipt of one or more EOS indications.) -Matt > -----Original Message----- > From: Matthew Heaney=20 > Sent: Monday, October 27, 2003 12:37 PM > To: Magnus Westerlund; Tom Marshall > Cc: mmusic@ietf.org; zeng@PacketVideo.COM > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to=20 > indicate end of medi a stream >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > Sent: Monday, October 27, 2003 4:46 AM > > To: Tom Marshall > >=20 > > 4. Use a RTP extension. > > This solution can either be implemented through a new RTP > > payload format=20 > > including the necessary information, or through some RTP=20 > > header extension. > > - Will go in the media channel as media rather than signalling. > > - Can't be sent in advance for certain media requiring=20 > continuos RTP=20 > > sequence numbers if it requires its own packets. > > - Is not robust will require that one either uses some type=20 > > of ACKs and=20 > > adaptive transmission of them or do a repetition accomplishing high=20 > > enough delivery probability. > > - The use of header extension would prevent other header extensions. > > - The use of a payload format would either require its own=20 > > RTP packet or=20 > > use of RFC 2198. >=20 > Other issues: >=20 > o What is the rtp timestamp of the EOS indication? >=20 > o If the EOS indication increments (rtp timestamps are=20 > "monotonically increasing"), then by how much should the=20 > timestamp increment for each EOS sent? >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 14:26:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02029 for ; Mon, 27 Oct 2003 14:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AED0E-000642-Et for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 14:26:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RJQAc9023303 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 14:26:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AED0E-00063m-9V for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 14:26:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01949 for ; Mon, 27 Oct 2003 14:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AED0B-0002bu-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 14:26:07 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AED0B-0002bq-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 14:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AED06-00061W-2S; Mon, 27 Oct 2003 14:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AECz9-0005rO-A6 for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 14:25:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01810 for ; Mon, 27 Oct 2003 14:24:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AECz6-0002Zb-00 for mmusic@ietf.org; Mon, 27 Oct 2003 14:25:00 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AECz6-0002Xe-00 for mmusic@ietf.org; Mon, 27 Oct 2003 14:25:00 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9RJONio004798; Mon, 27 Oct 2003 11:24:23 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 11:24:23 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BF3@misty.packetvideo.com> From: Thomas Zeng To: "'Matthew Heaney'" , Magnus Westerlund , Tom Marshall Cc: mmusic@ietf.org Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Mon, 27 Oct 2003 11:24:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) 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: Matthew Heaney [mailto:mheaney@on2.com] > Sent: Monday, October 27, 2003 11:19 AM > To: Matthew Heaney; Magnus Westerlund; Tom Marshall > Cc: mmusic@ietf.org; zeng@PacketVideo.COM > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to > indicate end of medi a stream > > > I suppose I should also bring up the issue of end-of-stream vs. > end-of-play. > > Perhaps it would be useful for the server to indicate that it's done > playing all the streams implied by the aggregate play request. Do you imply "end-of-play" should be signalled by RTSP server, then? > > (This actually requires some work in the TrueCast case, since each > stream is more or less independent. Right now I leave it up to the > client to decide when to issue the (aggregate) PAUSE or > TEARDOWN request > following receipt of one or more EOS indications.) > > -Matt > > > > -----Original Message----- > > From: Matthew Heaney > > Sent: Monday, October 27, 2003 12:37 PM > > To: Magnus Westerlund; Tom Marshall > > Cc: mmusic@ietf.org; zeng@PacketVideo.COM > > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to > > indicate end of medi a stream > > > > > > > > > > > -----Original Message----- > > > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > > > Sent: Monday, October 27, 2003 4:46 AM > > > To: Tom Marshall > > > > > > 4. Use a RTP extension. > > > This solution can either be implemented through a new RTP > > > payload format > > > including the necessary information, or through some RTP > > > header extension. > > > - Will go in the media channel as media rather than signalling. > > > - Can't be sent in advance for certain media requiring > > continuos RTP > > > sequence numbers if it requires its own packets. > > > - Is not robust will require that one either uses some type > > > of ACKs and > > > adaptive transmission of them or do a repetition > accomplishing high > > > enough delivery probability. > > > - The use of header extension would prevent other header > extensions. > > > - The use of a payload format would either require its own > > > RTP packet or > > > use of RFC 2198. > > > > Other issues: > > > > o What is the rtp timestamp of the EOS indication? > > > > o If the EOS indication increments (rtp timestamps are > > "monotonically increasing"), then by how much should the > > timestamp increment for each EOS sent? > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 15:21:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06547 for ; Mon, 27 Oct 2003 15:21:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDrO-0004NP-0i for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 15:21:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RKL564016814 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 15:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDrN-0004N7-QW for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 15:21:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06491 for ; Mon, 27 Oct 2003 15:20:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDrM-0003f3-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 15:21:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEDrL-0003f0-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 15:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDrK-0004MN-IW; Mon, 27 Oct 2003 15:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEDqv-0004Kn-6Q for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 15:20:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06479 for ; Mon, 27 Oct 2003 15:20:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEDqt-0003eg-00 for mmusic@ietf.org; Mon, 27 Oct 2003 15:20:35 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AEDqt-0003ed-00 for mmusic@ietf.org; Mon, 27 Oct 2003 15:20:35 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Mon, 27 Oct 2003 15:19:27 -0500 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Thread-Index: AcOcwBeddTqhPfXHQHqhUWahUHmFuwABlcqw From: "Matthew Heaney" To: "Thomas Zeng" , "Magnus Westerlund" , "Tom Marshall" Cc: X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Thomas Zeng [mailto:zeng@PacketVideo.COM]=20 > Sent: Monday, October 27, 2003 2:24 PM >=20 > > -----Original Message----- > > From: Matthew Heaney [mailto:mheaney@on2.com] > > Sent: Monday, October 27, 2003 11:19 AM > >=20 > > Perhaps it would be useful for the server to indicate that it's done > > playing all the streams implied by the aggregate play request. >=20 > Do you imply "end-of-play" should be signalled by RTSP server, then? I was thinking that if we treat the original play request as "atomic," that perhaps the server should indicate that the entire play request has finished. By "finished" I mean all the streams that entered the playing state as a result of the aggregate play request are done. If you send an EOS indicator for each stream separately, then it's up to the client to figure out when to move to another aggregate play state. Right now he must synthesize this information himself, based on how many streams were reported back in the RTP-Info of the PLAY response, and how many different EOS indicators he has received. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 17:15:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20677 for ; Mon, 27 Oct 2003 17:15:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFeB-0000Tq-Qe for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9RMFZvs001845 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFeB-0000Tg-MV for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 17:15:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20417 for ; Mon, 27 Oct 2003 17:15:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEFe9-0007Mx-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 17:15:33 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEFe8-0007Lw-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 17:15:32 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEFaG-0002G3-Pv for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 17:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZs-0007ju-DQ; Mon, 27 Oct 2003 17:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEFZT-0007dR-I5 for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 17:10:43 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19314; Mon, 27 Oct 2003 17:10:30 -0500 (EST) Message-Id: <200310272210.RAA19314@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: Mon, 27 Oct 2003 17:10:29 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdescriptions-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP Security Descriptions for Media Streams Author(s) : F. Andreasen, M. Baugher, D. Wing Filename : draft-ietf-mmusic-sdescriptions-02.txt Pages : 36 Date : 2003-10-24 This document defines a Session Description Protocol (SDP) cryptographic attribute for media streams. The attribute describes a cryptographic key and other parameters, which serve to configure security for a media stream. This document defines the Secure Real- time Transport Protocol (SRTP) parameters for the attribute. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdescriptions-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdescriptions-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-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-10-27171403.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdescriptions-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdescriptions-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-27171403.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Oct 27 23:19:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07041 for ; Mon, 27 Oct 2003 23:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AELK1-0004Gx-Vx for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 23:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S4J9q0016417 for mmusic-archive@odin.ietf.org; Mon, 27 Oct 2003 23:19:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AELK0-0004Gi-OL for mmusic-web-archive@optimus.ietf.org; Mon, 27 Oct 2003 23:19:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07036 for ; Mon, 27 Oct 2003 23:18:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AELJy-0005PH-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 23:19:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AELJy-0005PE-00 for mmusic-web-archive@ietf.org; Mon, 27 Oct 2003 23:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AELJv-0004FX-6C; Mon, 27 Oct 2003 23:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AELJ6-0004Dj-Py for mmusic@optimus.ietf.org; Mon, 27 Oct 2003 23:18:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07023; Mon, 27 Oct 2003 23:18:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AELJ4-0005Oz-00; Mon, 27 Oct 2003 23:18:10 -0500 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1AELJ3-0005Ot-00; Mon, 27 Oct 2003 23:18:09 -0500 Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id h9S4HYio019695; Mon, 27 Oct 2003 20:17:34 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Mon, 27 Oct 2003 20:17:34 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com> From: Thomas Zeng To: "'Matthew Heaney'" , Magnus Westerlund , Tom Marshall , Greg Sherwood , mmusic@ietf.org Cc: "'avt@ietf.org'" Date: Mon, 27 Oct 2003 20:17:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C39D0A.68A03730" Subject: [MMUSIC] FW: draft-zeng-mmusic-rtsp-end-of-stream-01.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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C39D0A.68A03730 Content-Type: text/plain; charset="iso-8859-1" Dear AVT and MMUSIC members: Last night, I submitted revision 01 of the strawman End-Of-Stream proposal, which is the action assigned to me during IETF-57. See forwarded email. In this revision, I added "Appendix A" to describe a new RTCP packet for singalling EOS: the RTCP EOS packet. My intention is to present both RTSP EOS and RTCP EOS, and open to the group to debate whether one or both of them (or none of them) should be standardized. Note that in my view defining a special RTP packet is inferior to new RTCP EOS packet, because RTCP is more suitable for control purposes. Therefor I didn't present an RTP based EOS solution. The final decision is up to the group. As always, your comments are highly appreciated. Given the differing opinions on EOS signalling, I'd like to request a 15 minutes time slot during MMUSIC session on Nov.14 to present these alternatives to the group. I will send a separate email to MMUSIC chairs shortly. Another note: In Appendix A, the sequence number of the ending RTP packet is given for each SSRC/CSRC in the new RTCP EOS packet. It appears to be enough and I don't see a need to also put RTP time of the ending RTP timestamp in the RTCP EOS packet. AVT mailing list is CC'ed since if we opt for a new RTCP EOS packet, AVT would be the WG to get approval. Thanks, - thomas > -----Original Message----- > From: Thomas Zeng > Sent: Sunday, October 26, 2003 10:34 PM > To: 'internet-drafts@ietf.org' > Subject: draft-zeng-mmusic-rtsp-end-of-stream-01.txt > > <> ------_=_NextPart_000_01C39D0A.68A03730 Content-Type: text/plain; name="draft-zeng-mmusic-rtsp-end-of-stream-01.txt" Content-Disposition: attachment; filename="draft-zeng-mmusic-rtsp-end-of-stream-01.txt" Content-Transfer-Encoding: quoted-printable =0A= MMUSIC Thomas M. = Zeng=0A= P. Greg = Sherwood=0A= Internet-Draft = PacketVideo=0A= Expires: April 29, 2004 Oct 26, = 2003=0A= =0A= =0A= Signalling End Of Stream in Real Time Streaming=0A= draft-zeng-mmusic-end-of-stream-01.txt=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that = other=0A= groups may also distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at http://=0A= www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on Apr. 29, 2004.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= This document describes a new RTSP method called END_OF_STREAM, = which =0A= extends the core RTSP protocol to enable one RTSP protocol entity to = =0A= signal other entity(s) =0A= that it has no more media data to send. This request could be issued = =0A= either with a =0A= non-aggregate or aggregate control URI, the latter implies that all = =0A= media streams =0A= in the aggregate session have run out of media data.=0A= =0A= The receiver of this RTSP request is expected to reply with 200 OK = =0A= response.=0A= =0A= Since END_OF_STREAM represents an extension to the core RTSP = protocol, =0A= a feature tag,=0A= "method.eos", is defined to facilitate capability negotiation using = =0A= RTSP extension =0A= mechanism [RTSP_NEW].=0A= =0A= =0A= 1. Motivation=0A= =0A= In the core RTSP protocol [RTSP_NEW], an RTSP client relies on = the=0A= media transport mechanism to signal end of stream.=0A= =0A= When the media transport mechanism happens to be RTP over UDP, this = =0A= is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are = =0A= some drawbacks with this approach:=0A= =0A= 1. When the server sends an RTCP BYE packet with its SSRC, the =0A= server is giving up=0A= the SSRC (see section 8.2 in [RTP_NEW]). The server would be = =0A= required to =0A= switch to a new SSRC on a subsequent PLAY of the same media =0A= stream.=0A= Since server's SSRC is only communicated in the Transport = header =0A= of SETUP =0A= response, the server would not have an opportunity to send a = new=0A= value to =0A= the player, and the client would have to discover the SSRC from = =0A= the incoming RTP packets. =0A= =0A= 2. RTCP BYE packet method does not offer a simple, gurranteed =0A= method of delievering=0A= an end-of-stream announcement.=0A= =0A= 3. RTCP BYE packet method does not offer the option to have a = single=0A= aggregate=0A= end-of-stream announcemnt for all media streams in the RTSP =0A= session.=0A= =0A= 4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot = =0A= send RTCP BYE =0A= before leaving the RTP session if it has not already sent at = =0A= least one RTP or RTCP packet. This is a problem under =0A= error conditions. Consider the case =0A= where an RTP session has just started (i.e., RTSP PLAY has =0A= been =0A= successfully acknowledged with an RTSP 200 OK response), and = the =0A= sender attempts to =0A= retrieve media frames from its media source. The media source = =0A= fails to provide any media frame due to its internal error such = =0A= as file corruption. The sender should inform its receiver(s) = =0A= but it cannot send BYE packets.=0A= =0A= The motivation to solve the above issues is particularly high for = =0A= unicast streaming applications that use RTSP over TCP in the control = =0A= plane, and RTP over UDP in the media transport. =0A= =0A= There is also the desire to have an EOS (End Of Stream) =0A= signalling mechanism =0A= for non-RTP delivery. One such delivery is MPEG2 transport streams = =0A= used in the cable TV environment. In non-IP delivery environments, = =0A= the transport typically remains allocated even if no media is being = =0A= delivered. This=0A= means that a client cannot watch for the server to close the=0A= transport to signal the end of stream. Meanwhile, watching for the = =0A= incoming media to stop is unreliable. Short=0A= timeouts can trigger a false end of media detection if the=0A= media flow is temporarily delayed. Long timeouts introduce=0A= unacceptable latencies. Clients are unable to distinguish=0A= between a normal end of stream and an error condition that=0A= resulted in the media delivery stopping.=0A= =0A= We note that using TEARDOWN from server to client is not =0A= appropriate because:=0A= 1. TEARDOWN is currently not allowed from server to =0A= client [RTSP_NEW];=0A= 2. Even if TEARDOWN is made available in server to client =0A= direction, =0A= the definition of TEARDOWN requires that, if the request =0A= URI is =0A= aggregate, that the session must be de-allocated by the =0A= server. =0A= There are RTSP applications that use SET_PARAMETER from =0A= client to=0A= server as the means to report session QoS statistics, but if=0A= server uses TEARDOWN on aggregate URL to signal end of stream, = =0A= the client can no longer use SET_PARAMETER with a =0A= session header. =0A= 3. In general, RTSP, being a client-server protocol,=0A= should let client, not server to control session state. But =0A= TEARDOWN=0A= on aggregate URL will change session from PLAYING state =0A= to INIT state.=0A= =0A= We note that using PAUSE from server to client is not appropriate = =0A= either, because PAUSE will change the state of the RTSP session.=0A= =0A= We note also that using ANNOUNCE from server to client is not =0A= suitable, for two reasons:=0A= 1. ANNOUNCE from server to client is used in RFC2326 to update = =0A= session description. =0A= Extending it to indicate end-of-stream event is awkward.=0A= 2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW].=0A= =0A= There has been proposals to extend RTP or RTCP protocol to = introduce=0A= in-band signalling of end-of-stream events. Appendex A explains=0A= one such proposal. We note that in practice both approaches =0A= (using an RTSP method or a special RTP/RTCP packet to signal=0A= end-of-stream) have shown up in propriatery implemtations. =0A= Therefore it is our view that allowing both approaches =0A= is a reasonable compromise until a concensus is reached. =0A= =0A= The next section describes our solution.=0A= =0A= 3. Solution Using END_OF_STREAM method=0A= =0A= We introduce a new RTSP method to signal end of stream in = applications=0A= where an persistent RTSP connection is maintained between server =0A= and client.=0A= The new method is an RTSP "extension-method" [RTSP_NEW]. It is = called=0A= END_OF_STREAM, and is a request from media sender=0A= to receiver. In the case of RTSP client playing media streams sent = by =0A= RTSP server,=0A= the END_OF_STREAM is sent from server to client. In the use case = where =0A= RTSP server is=0A= recording media sent by RTSP client, the END_OF_STREAM requet could = =0A= be sent from an=0A= RTSP client to server. =0A= =0A= As any other RTSP request method, END_OF_STREAM must be acknowledged = =0A= with a response.=0A= =0A= 3.1 The Definition of END_OF_STREAM=0A= =0A= The END_OF_STREAM request for a URI signals the fact that no more = =0A= RTP packets will be=0A= sent. Here is an example:=0A= =0A= S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0=0A= CSeq: 10=0A= Session: 12345678=0A= Range: npt=3D0-200=0A= RTP-Info: = url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102,=0A= url=3Drtsp://foo.com/bar.avi/streamid=3D1;seq=3D30211 = =0A= Reason: End of range reached=0A= =0A= C->S: RTSP/1.0 200 OK =0A= CSeq: 10=0A= Session: 12345678=0A= =0A= An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" = =0A= headers.=0A= It SHOULD include "RTP-Info" header.=0A= The RTP-Info in server's END_OF_STREAM request=0A= is used to indicate the sequence number of =0A= the ending RTP packet for each media stream.=0A= =0A= An END_OF_STREAM requet MAY include a new "Reason" header, =0A= defined as a =0A= string, whose purpose is to allow the server to explain why stream = =0A= has ended, and whose ABNF definition is given below:=0A= =0A= Reason =3D "Reason" ":" Reason-Phrase CRLF=0A= =0A= where:=0A= -- "Reason-Phrase" is a parameter defined in section 7.1.1 of = =0A= [RTSP_NEW].=0A= =0A= =0A= Note that the server is free to use any text as "Reason-Phrase". In = =0A= certain applications, the client=0A= may display the text, in its entirety, to end user to improve = user=0A= friendliness.=0A= =0A= END_OF_STREAM does not remove session ID, nor does it change the =0A= state of the RTSP session.=0A= =0A= END_OF_STREAM may be applied to either aggregate or non-aggregate = URI.=0A= =0A= END_OF_STREAM does not apply if the RTSP session is not in = PLAYING=0A= state. If a client receives END_OF_STREAM while it is not in PLAYING = =0A= state, it must reply with a 455 response: Method Not Valid in This = =0A= State.=0A= =0A= We note that client can piggy back QoS statistics as a entity body = in=0A= its 200 OK response to the END_OF_STREAM request from the server. = =0A= =0A= 3.2 Limitations=0A= =0A= END_OF_STREAM method is applicable only if the server has the = means=0A= to contact the client when it reaches the end of a media stream.=0A= This may not be possible if the RTSP connection between server = and=0A= client is not persistent. When it is time to send END_OF_STREAM = but=0A= the server does not have connection to the client, the server = will=0A= simply skip END_OF_STREAM. That is to say, the server will not =0A= queue up the END_OF_STREAM message.=0A= =0A= =0A= 4. Feature tag=0A= =0A= The END_OF_STREAM feature is represented by a feature tag (see =0A= [RTSP_NEW]=0A= for how to use feature tags in capability negotiations).=0A= =0A= The feature tag is:=0A= =0A= method.eos=0A= =0A= which means that the END_OF_STREAM method is fully supported. By =0A= fully we mean either at non-aggregate or aggregate level.=0A= =0A= 5. Use Case=0A= =0A= In this example, the server sends END_OF_STREAM request to client = for=0A= one live media stream, because upstream source terminates the = stream=0A= after 200 seconds. The fact that the stream has played for 200 = seconds=0A= is communicated by the Range header in the END_OF_STREAM request.=0A= =0A= C->S: PLAY rtsp://foo.com/bar.avi/streamid=3D0 RTSP/1.0=0A= Supported: method.eos=0A= CSeq: 10=0A= Session: 12345678=0A= Range: 0-200=0A= =0A= S->C: RTSP/1.0 200 OK=0A= Supported: method.eos=0A= CSeq: 10=0A= Session: 12345678=0A= RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D0; = rtptime=3D0 =0A= =0A= S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=3D0 = RTSP/1.0=0A= CSeq: 123=0A= Session: 12345678=0A= Range: npt=3D0-200; bytes=3D0-200000=0A= RTP-Info: url=3D//foo.com/bar.avi/streamid=3D0;seq=3D45102 = =0A= Reason: End of range reached=0A= =0A= C->S: RTSP/1.0 200 OK =0A= CSeq: 123=0A= Session: 12345678=0A= =0A= In the END_OF_STREAM request, the client will learn that the server = has =0A= completed the stream as requested (as indicated by the "End of range = =0A= reached" Reason).=0A= =0A= From the two RTP-Info headers, one in PLAY response, one in =0A= END_OF_STREAM requst, the client can derive the total number=0A= of RTP packets that the server has sent. From the npt field in the = =0A= Range header, the client knows the presentation time that this = stream =0A= has covered, from the server's point of view, while the byte-range = field =0A= can optional inform the =0A= client how much media data, in bytes, that the server has sent. =0A= =0A= 5. Security Considerations=0A= =0A= Because there is only one new TEXT header, "Reason", added by our = =0A= new RTSP method,=0A= the security considerations outlined in [RTSP_NEW] apply here as = well.=0A= =0A= 6. IANA Considerations=0A= =0A= A new method name, and its associated feature tag need to be = registered =0A= with IANA.=0A= =0A= -- Method name: END_OF_STREAM=0A= =0A= -- feature tag: method.eos=0A= =0A= =0A= =0C=0A= =0A= Appendix A: Signalling End-Of-Streaming With RTCP EOD Packet=0A= =0A= In this appendix, a new RTCP packet type is defined to signal=0A= end-of-stream event. =0A= =0A= A new RTCP packet type is prefered over profile specific extensions=0A= (see section 6.4.1 of [RTP-NEW])=0A= because this feature is profile independent.=0A= =0A= 1. EOS: End-Of-Stream RTCP Packet=0A= =0A= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= |V=3D2|P| SC | PT=3DEOS=3D205 | length = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | SSRC/CSRC = |=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= | extended RTP sequence number | = =0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= : ... = :=0A= = +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D= +=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=0A= (opt) | length | reason for EOS = ...=0A= = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=0A= =0A= The EOS packet indicates that one or more sources have exhausted = its=0A= media data and will not send any new RTP packet, yet the source is = =0A= not about to leave the session.=0A= =0A= packet type (PT): 8 bits=0A= Contains the constant 205 to idnentify this as an RTCP EOS = packet.=0A= =0A= source count (SC): 5 bits=0A= The number of SSRC/CSRC identifiers included in this EOS = packet.=0A= A count value of zero is valid, but useless. For each one of =0A= them, an extended RTP sequence number is included. See below.=0A= =0A= extended RTP sequence number: 32 bit=0A= The extended sequence number of the ending RTP packet from the =0A= source.=0A= The low 16 bits contain the sequence number of the ending RTP=0A= data packet from source SSRC_n, and the most significant 16=0A= bits extend that sequence number with the corresponding count of=0A= sequence number cycles. The RTP receiver needs to track the=0A= extended sequence number to properly generate RTCP=0A= RR packets, hence it can easily determine which RTP packet is = the=0A= ending RTP packet.=0A= =0A= 2. Rules of sending RTCP EOS packet=0A= =0A= RTCP EOS packet should be sent if the source runs out of media = data,=0A= but is NOT about to leave the session. It may, for instance, wait=0A= for the receiver to send anther RTSP PLAY request (if RTSP is the=0A= session contorl protocol in use) and then re-use the SSRC to send=0A= RTP packets.=0A= =0A= If an EOS packet is received by a mixer, the mixer SHOULD forward=0A= the EOS packet with its SSRC/CSRC identifier(s) unchanged.=0A= =0A= Optionally, the EOS packet MAY include an 8-bit octet count =0A= followed by that many=0A= octets of text indicating the reason for ending, e.g., "End of file" = =0A= or "Upstream EOS received". The string has the same=0A= encoding as that described for SDES. If the string fills the = packet=0A= to the next 32-bit boundary, the string is not null terminated. = If=0A= not, the EOS packet MUST be padded with null octets to the next = 32-=0A= bit boundary. This padding is separate from that indicated by the = P=0A= bit in the RTCP header.=0A= =0A= When RTP is carried over un-reliable transport (e.g., UDP), an RTP = =0A= source may repeatedly send RTCP EOS packets until it is assured = that=0A= the receiver(s) have got the event notification -- e.g., it has=0A= received another RTSP PLAY request from the RTP receiver. =0A= =0A= ^L=0A= Normative References=0A= =0A= [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., = =0A= "Real Time Streaming Protocol", =0A= draft-ietf-mmusic-rfc2326bis-04.txt=0A= =0A= [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assignees.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= =0A= =0A= =0A= =0A= =0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Acknowledgement=0A= =0A= Thanks to Sean Sheedy for suggesting the inclusion of "Range" = header=0A= and for contributing some text in the motivations section.=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= Author Addresses=0A= =0A= Thomas Zeng=0A= PacketVideo Corp.=0A= 10350 Science Center Dr., Suite 210=0A= San Diego, CA 92127=0A= email: zeng@pv.com=0A= =0A= P. Greg Sherwood=0A= PacketVideo Corp.=0A= 10350 Science Center Dr., Suite 210=0A= San Diego, CA 92127=0A= email: sherwood@pv.com ------_=_NextPart_000_01C39D0A.68A03730-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 04:03:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10570 for ; Tue, 28 Oct 2003 04:03:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPkq-000093-K6 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 04:03:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S938xZ000547 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 04:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPkp-00008R-9R for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:03:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10501 for ; Tue, 28 Oct 2003 04:02:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPkm-0005oi-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 04:03:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEPkl-0005ob-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 04:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPkm-000087-5A; Tue, 28 Oct 2003 04:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPk9-0008Tw-Oy for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 04:02:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10430 for ; Tue, 28 Oct 2003 04:02:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPk6-0005nZ-00 for mmusic@ietf.org; Tue, 28 Oct 2003 04:02:22 -0500 Received: from [212.68.150.1] (helo=embexcil02.emblaze.ent) by ietf-mx with esmtp (Exim 4.12) id 1AEPk6-0005nQ-00 for mmusic@ietf.org; Tue, 28 Oct 2003 04:02:22 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Tue, 28 Oct 2003 11:02:21 +0200 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Thread-Index: AcOcwBeddTqhPfXHQHqhUWahUHmFuwABlcqwABrIlzA= From: "Amir Wolf" To: "Matthew Heaney" , "Thomas Zeng" , "Magnus Westerlund" , "Tom Marshall" Cc: Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi All, I think that signaling EOS per stream has more value since one of the = most helpful uses of this feature is when you play a very low fps video = e.g. average of 1/4 fps and audio. It is important for the player to know when video ends, while it can = easily identify end of session by getting the required duration.=20 > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On=20 > Behalf Of Matthew Heaney > Sent: Monday, October 27, 2003 10:19 PM > To: Thomas Zeng; Magnus Westerlund; Tom Marshall > Cc: mmusic@ietf.org > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to=20 > indicate end of medi a stream >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Thomas Zeng [mailto:zeng@PacketVideo.COM]=20 > > Sent: Monday, October 27, 2003 2:24 PM > >=20 > > > -----Original Message----- > > > From: Matthew Heaney [mailto:mheaney@on2.com] > > > Sent: Monday, October 27, 2003 11:19 AM > > >=20 > > > Perhaps it would be useful for the server to indicate=20 > that it's done > > > playing all the streams implied by the aggregate play request. > >=20 > > Do you imply "end-of-play" should be signalled by RTSP server, then? >=20 > I was thinking that if we treat the original play request as "atomic," > that perhaps the server should indicate that the entire play=20 > request has > finished. By "finished" I mean all the streams that entered=20 > the playing > state as a result of the aggregate play request are done. >=20 > If you send an EOS indicator for each stream separately, then=20 > it's up to > the client to figure out when to move to another aggregate play state. > Right now he must synthesize this information himself, based=20 > on how many > streams were reported back in the RTP-Info of the PLAY=20 > response, and how > many different EOS indicators he has received. >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 04:14:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11019 for ; Tue, 28 Oct 2003 04:14:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPvR-0001K9-Cv for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 04:14:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9S9E5XV005088 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 04:14:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPvQ-0001Jq-8t for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 04:14:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11013 for ; Tue, 28 Oct 2003 04:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPvN-00060N-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 04:14:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEPvM-00060I-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 04:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPvO-0001JH-2t; Tue, 28 Oct 2003 04:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEPv6-0001IF-Sn for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 04:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11002; Tue, 28 Oct 2003 04:13:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEPv3-0005zz-00; Tue, 28 Oct 2003 04:13:41 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AEPv2-0005zl-00; Tue, 28 Oct 2003 04:13:40 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9S9D3I2026095; Tue, 28 Oct 2003 10:13:03 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VXCB1VR4; Tue, 28 Oct 2003 10:13:07 +0100 Message-ID: <3F9E330E.60006@ericsson.com> Date: Tue, 28 Oct 2003 10:12:46 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund Reply-To: IETF MMUSIC WG User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org CC: "'avt@ietf.org'" References: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com> In-Reply-To: <72263E8E8622D611975C0002B32C19D805A17BF6@misty.packetvideo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: FW: draft-zeng-mmusic-rtsp-end-of-stream-01.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 Hi, If you have comments on this, lets discuss this on the MMUSIC list. So no future cross postings. Cheers Magnus Thomas Zeng wrote: > Dear AVT and MMUSIC members: > > Last night, I submitted revision 01 of the strawman End-Of-Stream proposal, > which is the action assigned to me during IETF-57. > See forwarded email. > > In this revision, I added "Appendix A" to describe a new RTCP packet for > singalling EOS: the RTCP EOS packet. > My intention is to present both RTSP EOS and RTCP EOS, and open to the > group to debate whether one or both of them (or none > of them) should be standardized. > > Note that in my view defining a special RTP packet is inferior to new RTCP > EOS packet, because RTCP is more suitable for control purposes. > Therefor I didn't present an RTP based EOS solution. The final decision is > up to the group. > > As always, your comments are highly appreciated. > > Given the differing opinions on EOS signalling, I'd like to request a 15 > minutes time slot during MMUSIC session on Nov.14 to > present these alternatives to the group. I will send a separate email to > MMUSIC chairs shortly. > > Another note: > In Appendix A, the sequence number of the ending RTP packet is given for > each SSRC/CSRC in the new RTCP EOS packet. > It appears to be enough and I don't see a need to also put RTP time of the > ending RTP timestamp in the RTCP EOS packet. > > AVT mailing list is CC'ed since if we opt for a new RTCP EOS packet, AVT > would be the WG to get approval. > > Thanks, > - thomas > > > >> -----Original Message----- >>From: Thomas Zeng >>Sent: Sunday, October 26, 2003 10:34 PM >>To: 'internet-drafts@ietf.org' >>Subject: draft-zeng-mmusic-rtsp-end-of-stream-01.txt >> >> <> > > > > ------------------------------------------------------------------------ > > > MMUSIC Thomas M. Zeng > P. Greg Sherwood > Internet-Draft PacketVideo > Expires: April 29, 2004 Oct 26, 2003 > > > Signalling End Of Stream in Real Time Streaming > draft-zeng-mmusic-end-of-stream-01.txt > > Status of this Memo > > This document is an Internet-Draft and is in full conformance with > all provisions of Section 10 of RFC2026. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that other > groups may also distribute working documents as Internet-Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at http:// > www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on Apr. 29, 2004. > > Copyright Notice > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > Abstract > > This document describes a new RTSP method called END_OF_STREAM, which > extends the core RTSP protocol to enable one RTSP protocol entity to > signal other entity(s) > that it has no more media data to send. This request could be issued > either with a > non-aggregate or aggregate control URI, the latter implies that all > media streams > in the aggregate session have run out of media data. > > The receiver of this RTSP request is expected to reply with 200 OK > response. > > Since END_OF_STREAM represents an extension to the core RTSP protocol, > a feature tag, > "method.eos", is defined to facilitate capability negotiation using > RTSP extension > mechanism [RTSP_NEW]. > > > 1. Motivation > > In the core RTSP protocol [RTSP_NEW], an RTSP client relies on the > media transport mechanism to signal end of stream. > > When the media transport mechanism happens to be RTP over UDP, this > is carried out by RTCP BYE packet [RTP_NEW]. In practice, there are > some drawbacks with this approach: > > 1. When the server sends an RTCP BYE packet with its SSRC, the > server is giving up > the SSRC (see section 8.2 in [RTP_NEW]). The server would be > required to > switch to a new SSRC on a subsequent PLAY of the same media > stream. > Since server's SSRC is only communicated in the Transport header > of SETUP > response, the server would not have an opportunity to send a new > value to > the player, and the client would have to discover the SSRC from > the incoming RTP packets. > > 2. RTCP BYE packet method does not offer a simple, gurranteed > method of delievering > an end-of-stream announcement. > > 3. RTCP BYE packet method does not offer the option to have a single > aggregate > end-of-stream announcemnt for all media streams in the RTSP > session. > > 4. Section 6.3.7 of RFC3550 stipulates that an RTP sender cannot > send RTCP BYE > before leaving the RTP session if it has not already sent at > least one RTP or RTCP packet. This is a problem under > error conditions. Consider the case > where an RTP session has just started (i.e., RTSP PLAY has > been > successfully acknowledged with an RTSP 200 OK response), and the > sender attempts to > retrieve media frames from its media source. The media source > fails to provide any media frame due to its internal error such > as file corruption. The sender should inform its receiver(s) > but it cannot send BYE packets. > > The motivation to solve the above issues is particularly high for > unicast streaming applications that use RTSP over TCP in the control > plane, and RTP over UDP in the media transport. > > There is also the desire to have an EOS (End Of Stream) > signalling mechanism > for non-RTP delivery. One such delivery is MPEG2 transport streams > used in the cable TV environment. In non-IP delivery environments, > the transport typically remains allocated even if no media is being > delivered. This > means that a client cannot watch for the server to close the > transport to signal the end of stream. Meanwhile, watching for the > incoming media to stop is unreliable. Short > timeouts can trigger a false end of media detection if the > media flow is temporarily delayed. Long timeouts introduce > unacceptable latencies. Clients are unable to distinguish > between a normal end of stream and an error condition that > resulted in the media delivery stopping. > > We note that using TEARDOWN from server to client is not > appropriate because: > 1. TEARDOWN is currently not allowed from server to > client [RTSP_NEW]; > 2. Even if TEARDOWN is made available in server to client > direction, > the definition of TEARDOWN requires that, if the request > URI is > aggregate, that the session must be de-allocated by the > server. > There are RTSP applications that use SET_PARAMETER from > client to > server as the means to report session QoS statistics, but if > server uses TEARDOWN on aggregate URL to signal end of stream, > the client can no longer use SET_PARAMETER with a > session header. > 3. In general, RTSP, being a client-server protocol, > should let client, not server to control session state. But > TEARDOWN > on aggregate URL will change session from PLAYING state > to INIT state. > > We note that using PAUSE from server to client is not appropriate > either, because PAUSE will change the state of the RTSP session. > > We note also that using ANNOUNCE from server to client is not > suitable, for two reasons: > 1. ANNOUNCE from server to client is used in RFC2326 to update > session description. > Extending it to indicate end-of-stream event is awkward. > 2. ANNOUNCE is not in the core RTSP protocol [RTSP_NEW]. > > There has been proposals to extend RTP or RTCP protocol to introduce > in-band signalling of end-of-stream events. Appendex A explains > one such proposal. We note that in practice both approaches > (using an RTSP method or a special RTP/RTCP packet to signal > end-of-stream) have shown up in propriatery implemtations. > Therefore it is our view that allowing both approaches > is a reasonable compromise until a concensus is reached. > > The next section describes our solution. > > 3. Solution Using END_OF_STREAM method > > We introduce a new RTSP method to signal end of stream in applications > where an persistent RTSP connection is maintained between server > and client. > The new method is an RTSP "extension-method" [RTSP_NEW]. It is called > END_OF_STREAM, and is a request from media sender > to receiver. In the case of RTSP client playing media streams sent by > RTSP server, > the END_OF_STREAM is sent from server to client. In the use case where > RTSP server is > recording media sent by RTSP client, the END_OF_STREAM requet could > be sent from an > RTSP client to server. > > As any other RTSP request method, END_OF_STREAM must be acknowledged > with a response. > > 3.1 The Definition of END_OF_STREAM > > The END_OF_STREAM request for a URI signals the fact that no more > RTP packets will be > sent. Here is an example: > > S->C: END_OF_STREAM rtsp://foo.com/bar.avi RTSP/1.0 > CSeq: 10 > Session: 12345678 > Range: npt=0-200 > RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102, > url=rtsp://foo.com/bar.avi/streamid=1;seq=30211 > Reason: End of range reached > > C->S: RTSP/1.0 200 OK > CSeq: 10 > Session: 12345678 > > An END_OF_STREAM request MUST include "CSeq", "Range" and "Session" > headers. > It SHOULD include "RTP-Info" header. > The RTP-Info in server's END_OF_STREAM request > is used to indicate the sequence number of > the ending RTP packet for each media stream. > > An END_OF_STREAM requet MAY include a new "Reason" header, > defined as a > string, whose purpose is to allow the server to explain why stream > has ended, and whose ABNF definition is given below: > > Reason = "Reason" ":" Reason-Phrase CRLF > > where: > -- "Reason-Phrase" is a parameter defined in section 7.1.1 of > [RTSP_NEW]. > > > Note that the server is free to use any text as "Reason-Phrase". In > certain applications, the client > may display the text, in its entirety, to end user to improve user > friendliness. > > END_OF_STREAM does not remove session ID, nor does it change the > state of the RTSP session. > > END_OF_STREAM may be applied to either aggregate or non-aggregate URI. > > END_OF_STREAM does not apply if the RTSP session is not in PLAYING > state. If a client receives END_OF_STREAM while it is not in PLAYING > state, it must reply with a 455 response: Method Not Valid in This > State. > > We note that client can piggy back QoS statistics as a entity body in > its 200 OK response to the END_OF_STREAM request from the server. > > 3.2 Limitations > > END_OF_STREAM method is applicable only if the server has the means > to contact the client when it reaches the end of a media stream. > This may not be possible if the RTSP connection between server and > client is not persistent. When it is time to send END_OF_STREAM but > the server does not have connection to the client, the server will > simply skip END_OF_STREAM. That is to say, the server will not > queue up the END_OF_STREAM message. > > > 4. Feature tag > > The END_OF_STREAM feature is represented by a feature tag (see > [RTSP_NEW] > for how to use feature tags in capability negotiations). > > The feature tag is: > > method.eos > > which means that the END_OF_STREAM method is fully supported. By > fully we mean either at non-aggregate or aggregate level. > > 5. Use Case > > In this example, the server sends END_OF_STREAM request to client for > one live media stream, because upstream source terminates the stream > after 200 seconds. The fact that the stream has played for 200 seconds > is communicated by the Range header in the END_OF_STREAM request. > > C->S: PLAY rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 > Supported: method.eos > CSeq: 10 > Session: 12345678 > Range: 0-200 > > S->C: RTSP/1.0 200 OK > Supported: method.eos > CSeq: 10 > Session: 12345678 > RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=0; rtptime=0 > > S->C: END_OF_STREAM rtsp://foo.com/bar.avi/streamid=0 RTSP/1.0 > CSeq: 123 > Session: 12345678 > Range: npt=0-200; bytes=0-200000 > RTP-Info: url=//foo.com/bar.avi/streamid=0;seq=45102 > Reason: End of range reached > > C->S: RTSP/1.0 200 OK > CSeq: 123 > Session: 12345678 > > In the END_OF_STREAM request, the client will learn that the server has > completed the stream as requested (as indicated by the "End of range > reached" Reason). > > From the two RTP-Info headers, one in PLAY response, one in > END_OF_STREAM requst, the client can derive the total number > of RTP packets that the server has sent. From the npt field in the > Range header, the client knows the presentation time that this stream > has covered, from the server's point of view, while the byte-range field > can optional inform the > client how much media data, in bytes, that the server has sent. > > 5. Security Considerations > > Because there is only one new TEXT header, "Reason", added by our > new RTSP method, > the security considerations outlined in [RTSP_NEW] apply here as well. > > 6. IANA Considerations > > A new method name, and its associated feature tag need to be registered > with IANA. > > -- Method name: END_OF_STREAM > > -- feature tag: method.eos > > > > > Appendix A: Signalling End-Of-Streaming With RTCP EOD Packet > > In this appendix, a new RTCP packet type is defined to signal > end-of-stream event. > > A new RTCP packet type is prefered over profile specific extensions > (see section 6.4.1 of [RTP-NEW]) > because this feature is profile independent. > > 1. EOS: End-Of-Stream RTCP Packet > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |V=2|P| SC | PT=EOS=205 | length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SSRC/CSRC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | extended RTP sequence number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > : ... : > +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ > (opt) | length | reason for EOS ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The EOS packet indicates that one or more sources have exhausted its > media data and will not send any new RTP packet, yet the source is > not about to leave the session. > > packet type (PT): 8 bits > Contains the constant 205 to idnentify this as an RTCP EOS packet. > > source count (SC): 5 bits > The number of SSRC/CSRC identifiers included in this EOS packet. > A count value of zero is valid, but useless. For each one of > them, an extended RTP sequence number is included. See below. > > extended RTP sequence number: 32 bit > The extended sequence number of the ending RTP packet from the > source. > The low 16 bits contain the sequence number of the ending RTP > data packet from source SSRC_n, and the most significant 16 > bits extend that sequence number with the corresponding count of > sequence number cycles. The RTP receiver needs to track the > extended sequence number to properly generate RTCP > RR packets, hence it can easily determine which RTP packet is the > ending RTP packet. > > 2. Rules of sending RTCP EOS packet > > RTCP EOS packet should be sent if the source runs out of media data, > but is NOT about to leave the session. It may, for instance, wait > for the receiver to send anther RTSP PLAY request (if RTSP is the > session contorl protocol in use) and then re-use the SSRC to send > RTP packets. > > If an EOS packet is received by a mixer, the mixer SHOULD forward > the EOS packet with its SSRC/CSRC identifier(s) unchanged. > > Optionally, the EOS packet MAY include an 8-bit octet count > followed by that many > octets of text indicating the reason for ending, e.g., "End of file" > or "Upstream EOS received". The string has the same > encoding as that described for SDES. If the string fills the packet > to the next 32-bit boundary, the string is not null terminated. If > not, the EOS packet MUST be padded with null octets to the next 32- > bit boundary. This padding is separate from that indicated by the P > bit in the RTCP header. > > When RTP is carried over un-reliable transport (e.g., UDP), an RTP > source may repeatedly send RTCP EOS packets until it is assured that > the receiver(s) have got the event notification -- e.g., it has > received another RTSP PLAY request from the RTP receiver. > > ^L > Normative References > > [RTSP_NEW] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., > "Real Time Streaming Protocol", > draft-ietf-mmusic-rfc2326bis-04.txt > > [RTP_NEW] RFC3550 "Real-time Transport Protocol", July 2003 > > > Full Copyright Statement > > Copyright (C) The Internet Society (2003). All Rights Reserved. > > This document and translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it > or assist in its implementation may be prepared, copied, published > and distributed, in whole or in part, without restriction of any > kind, provided that the above copyright notice and this paragraph are > included on all such copies and derivative works. However, this > document itself may not be modified in any way, such as by removing > the copyright notice or references to the Internet Society or other > Internet organizations, except as needed for the purpose of > developing Internet standards in which case the procedures for > copyrights defined in the Internet Standards process must be > followed, or as required to translate it into languages other than > English. > > The limited permissions granted above are perpetual and will not be > revoked by the Internet Society or its successors or assignees. > > This document and the information contained herein is provided on an > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING > TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING > BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION > > > > > > HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF > MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. > > > Acknowledgement > > Thanks to Sean Sheedy for suggesting the inclusion of "Range" header > and for contributing some text in the motivations section. > > Funding for the RFC Editor function is currently provided by the > Internet Society. > > Author Addresses > > Thomas Zeng > PacketVideo Corp. > 10350 Science Center Dr., Suite 210 > San Diego, CA 92127 > email: zeng@pv.com > > P. Greg Sherwood > PacketVideo Corp. > 10350 Science Center Dr., Suite 210 > San Diego, CA 92127 > email: sherwood@pv.com -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 09:22:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22632 for ; Tue, 28 Oct 2003 09:22:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUjj-0002IB-2Z for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 09:22:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SEMJZ3008807 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 09:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUji-0002Hy-Vj for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 09:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22487 for ; Tue, 28 Oct 2003 09:22:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEUjg-0003c8-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 09:22:16 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEUjT-0003bk-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 09:22:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUjU-0002Be-0T; Tue, 28 Oct 2003 09:22:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEUjM-00029E-7Y for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 09:21:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22418; Tue, 28 Oct 2003 09:21:44 -0500 (EST) Message-Id: <200310281421.JAA22418@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, 28 Oct 2003 09:21:43 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf 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 : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne Filename : draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf Pages : 147 Date : 2003-10-27 This memorandum is a revision of RFC 2326, which is currently a Pro- posed Standard. The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over the delivery of data with real-time properties. RTSP provides an extensible framework to enable con- trolled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions, provide a means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for choosing delivery mechanisms based upon RTP (RFC 1889). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-28094130.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28094130.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 11:30:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05962 for ; Tue, 28 Oct 2003 11:30:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWj6-0001Mh-To for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 11:29:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SGTmgX005243 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 11:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWj6-0001ML-QE for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 11:29:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05801 for ; Tue, 28 Oct 2003 11:29:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEWj4-0000E7-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 11:29:46 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEWgT-0007lv-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 11:27:05 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEWVs-00009Q-LD for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 11:16:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWVl-0008Sv-FN; Tue, 28 Oct 2003 11:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEWVO-0008Qi-66 for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 11:15:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04683 for ; Tue, 28 Oct 2003 11:15:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEWVM-0007Xo-00 for mmusic@ietf.org; Tue, 28 Oct 2003 11:15:36 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AEWVM-0007Xl-00 for mmusic@ietf.org; Tue, 28 Oct 2003 11:15:36 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Date: Tue, 28 Oct 2003 11:14:44 -0500 Message-ID: Thread-Topic: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream Thread-Index: AcOcwBeddTqhPfXHQHqhUWahUHmFuwABlcqwABrIlzAADbu1YA== From: "Matthew Heaney" To: "Amir Wolf" , "Thomas Zeng" , "Magnus Westerlund" , "Tom Marshall" Cc: , "Frank Galligan" , "Tom Finegan" , "James Zern" X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Amir Wolf [mailto:Amir.Wolf@emblaze.com] > Sent: Tuesday, October 28, 2003 4:02 AM > I think that signaling EOS per stream has more value since > one of the most helpful uses of this feature is when you play=20 > a very low fps video e.g. average of 1/4 fps and audio. It is=20 > important for the player to know when video ends, while it=20 > can easily identify end of session by getting the required duration.=20 What do you mean by "required duration"? The value of the RTSP Range header, or something else? The problem is a PLAY request. At least in the current spec, if a play-with-range request is received while a previous play request is still playing, the server is supposed to queue the request. A play-sans-range request is a query if the server is still playing, but causes a state change if the server is not playing. The problem is defining what "still playing" means. In the normal case the audio and video streams are never exactly the same duration, so one stream can easily finish before another. (The is especially true in the TrueCast case, because I try to stay 5 sec. ahead of real-time for audio, so that stream will definitely finish first.) So if one stream finishes, does this mean the original play request is "still playing," because not all of the streams are done? This is what I was alluding to in my previous post about a play request being "atomic." The issue is that if the client must synthesize whether the server thinks it's done, by keeping track of the different EOS indicators, then the client might reach a conclusion that's different from the server. If the server says that it's done, then there is no ambiguity. This can be a problem if the client issues a play request (say, sans range header), because he doesn't know apriori whether the server will treat this as a no-op query, or actually start playing, unless the client knows the exact state of the server. The RTSP spec isn't very helpful on this point, because it doesn't clearly define what "still playing" means for an aggregate play request. > > -----Original Message----- > > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf=20 > > Of Matthew Heaney > > Sent: Monday, October 27, 2003 10:19 PM > > To: Thomas Zeng; Magnus Westerlund; Tom Marshall > > Cc: mmusic@ietf.org > > Subject: RE: [MMUSIC] [ rtspspec-Bugs-810678 ] How to > > indicate end of medi a stream > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Thomas Zeng [mailto:zeng@PacketVideo.COM] > > > Sent: Monday, October 27, 2003 2:24 PM > > >=20 > > > > -----Original Message----- > > > > From: Matthew Heaney [mailto:mheaney@on2.com] > > > > Sent: Monday, October 27, 2003 11:19 AM > > > >=20 > > > > Perhaps it would be useful for the server to indicate > > that it's done > > > > playing all the streams implied by the aggregate play request. > > >=20 > > > Do you imply "end-of-play" should be signalled by RTSP > server, then? > >=20 > > I was thinking that if we treat the original play request > as "atomic," > > that perhaps the server should indicate that the entire > play request > > has finished. By "finished" I mean all the streams that entered the > > playing state as a result of the aggregate play request are done. > >=20 > > If you send an EOS indicator for each stream separately, then it's=20 > > up to the client to figure out when to move to another aggregate > play state. > > Right now he must synthesize this information himself, based > > on how many > > streams were reported back in the RTP-Info of the PLAY=20 > > response, and how > > many different EOS indicators he has received. > >=20 > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic > >=20 >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 11:51:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07419 for ; Tue, 28 Oct 2003 11:51:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEX3h-0003RY-UT for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 11:51:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SGp5HI013235 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 11:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEX3h-0003RO-RY for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 11:51:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07388 for ; Tue, 28 Oct 2003 11:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEX3g-0000ra-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 11:51:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEX3g-0000rX-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 11:51:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEX3d-0003QU-Km; Tue, 28 Oct 2003 11:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEX3O-0003PO-LO for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 11:50:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07382 for ; Tue, 28 Oct 2003 11:50:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEX3N-0000rM-00 for mmusic@ietf.org; Tue, 28 Oct 2003 11:50:45 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AEX3M-0000rJ-00 for mmusic@ietf.org; Tue, 28 Oct 2003 11:50:44 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9SGoeI2004306; Tue, 28 Oct 2003 17:50:40 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VXCBJ1TB; Tue, 28 Oct 2003 17:50:46 +0100 Message-ID: <3F9E9E4F.5020607@ericsson.com> Date: Tue, 28 Oct 2003 17:50:23 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Heaney CC: mmusic@ietf.org Subject: Re: [MMUSIC] [ rtspspec-Bugs-810678 ] How to indicate end of medi a stream References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Matthew, I can do one simplification for you. When we are discussing an End of stream or play request we are doing this in the context of the updated specification. However I do see that there is probably need to make some short considerations on how this will interoperate with RFC 2326 implementation. However if you are not familiar with the currently ongoing work on updating RTSP you can start with looking at the latest draft version. However I will already now make it clear that the draft is not publication ready. We authors are hoping to get a version out before christmas that actual incorporates all decided fixes to the protocol. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt The current RTSP is a protocol stripping away all functionality that was not implemented in RFC 2326. So the following functionality has been removed: - Queued play - Record and Announce methods. - Use of non-aggregated play and pause control in Aggregated sessions. More information about this work can be seen on: http://rtsp.org http://rtspspec.sourceforge.net In regards to the end of media/play request fulfilled signalling this does not change much. However your arguments about separating initial and any queued play is probably not a argument we would give much attention to. This allows me to bring up a discussion on why this signalling is need. Reasons I see: - For living signalling without a predestined end of the session. In this case it seems the main goal is to inform the client that session has ended. Possibly a user readable reason is desirable to be given, Like "Tonight's jam session has now ended, come back next Tuesday for more interesting music!". The timing of this is that the message should be possible to give as soon as the last media has been played out. - To allow the transport handler in the client to know what the last packet it will receive to prevent unsecurity about buffering handling, retransmission. Thus it is desired to know before the last packet is received that it will be the last one. This is true independently of the session type. - To inform the client about that the play request has been fulfilled and all media streams will be delivered when the given packets has been received. However for media streams that has a determined length and for PLAY requests with closed ranges this information is derivable to a high degree. The exact sequence number can't be determined, however the RTP timestamp for the end of the request can be determined. - Something new which we haven't discussed so far is: Error information. If the server fails to fulfil the request during the playout. Using a server->client message the server can inform the client that the delivery has failed, why, and at which point in the media stream. Are there any more reasons for having something like this? I would also like to make people aware that depending on what usage are the most important the preferred choice of delivery is different. Cheers Magnus Matthew Heaney wrote: > >>-----Original Message----- >>From: Amir Wolf [mailto:Amir.Wolf@emblaze.com] >>Sent: Tuesday, October 28, 2003 4:02 AM > > >>I think that signaling EOS per stream has more value since >>one of the most helpful uses of this feature is when you play >>a very low fps video e.g. average of 1/4 fps and audio. It is >>important for the player to know when video ends, while it >>can easily identify end of session by getting the required duration. > > > What do you mean by "required duration"? The value of the RTSP Range > header, or something else? > > The problem is a PLAY request. At least in the current spec, if a > play-with-range request is received while a previous play request is > still playing, the server is supposed to queue the request. A > play-sans-range request is a query if the server is still playing, but > causes a state change if the server is not playing. > > The problem is defining what "still playing" means. In the normal case > the audio and video streams are never exactly the same duration, so one > stream can easily finish before another. (The is especially true in the > TrueCast case, because I try to stay 5 sec. ahead of real-time for > audio, so that stream will definitely finish first.) > > So if one stream finishes, does this mean the original play request is > "still playing," because not all of the streams are done? This is what > I was alluding to in my previous post about a play request being > "atomic." > > The issue is that if the client must synthesize whether the server > thinks it's done, by keeping track of the different EOS indicators, then > the client might reach a conclusion that's different from the server. > If the server says that it's done, then there is no ambiguity. > > This can be a problem if the client issues a play request (say, sans > range header), because he doesn't know apriori whether the server will > treat this as a no-op query, or actually start playing, unless the > client knows the exact state of the server. > > The RTSP spec isn't very helpful on this point, because it doesn't > clearly define what "still playing" means for an aggregate play request. > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 13:04:20 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13440 for ; Tue, 28 Oct 2003 13:04:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYCI-0003vY-S7 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 13:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SI42hc015095 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 13:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYCI-0003vO-Ne for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 13:04:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13424 for ; Tue, 28 Oct 2003 13:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYCG-0003A0-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 13:04:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEYCG-00039w-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 13:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYCH-0003uk-P6; Tue, 28 Oct 2003 13:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEYBf-0003sA-F7 for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 13:03:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13400 for ; Tue, 28 Oct 2003 13:03:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEYBd-00039C-00 for mmusic@ietf.org; Tue, 28 Oct 2003 13:03:21 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=virago) by ietf-mx with esmtp (Exim 4.12) id 1AEYBc-000390-00 for mmusic@ietf.org; Tue, 28 Oct 2003 13:03:21 -0500 Received: from tommy by virago with local (Exim 3.36 #1 (Debian)) id 1AEYBT-0002mK-00 for ; Tue, 28 Oct 2003 10:03:11 -0800 Date: Tue, 28 Oct 2003 10:03:11 -0800 From: Tom Marshall To: mmusic@ietf.org Message-ID: <20031028180311.GA9758@real.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: [MMUSIC] RTSP versioning 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: , --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been given the task of recoding the RTSP versioning support in our server (it currently is pretty much nonexistent). Since the draft spec is nearing completion, this might be a good time to clarify how versioning should be handled. I've collected a few datapoints... * RFC 2326 3.1 references RFC 2068 3.1. It says, in part: The number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The number is incremented when the format of a message within the protocol is changed. * Apache (both 1.3.x and 2.0.x) will respond v1.1 for a v1.0+ request. eg: GET / HTTP/1.0 Host: localhost HTTP/1.1 200 OK [...] GET / HTTP/2.0 Host: localhost HTTP/1.1 200 OK [...] * IIS 6.0 will respond v1.0 for a v1.0 request and v1.1 for a v1.1+ request= =2E=20 eg: GET / HTTP/1.0 Host: www.microsoft.com HTTP/1.0 200 OK [...] GET / HTTP/1.1 Host: www.microsoft.com HTTP/1.1 200 OK [...] GET / HTTP/1.2 Host: www.microsoft.com HTTP/1.1 200 OK [...] GET / HTTP/2.0 Host: www.microsoft.com HTTP/1.1 200 OK [...] That is really all the information we have for RTSP in the strictest sense, because RFC 2616 was written after RFC 2326 and RFC 2145 is never referenced in RFC 2326. However, since RFC 2145 applies to HTTP/1.1 (and thus RTSP/1.0 by extension), and it was written prior to RFC 2326, it might provide some valuable information for us. According to section 2.3, it appears to me that Apache properly implements the recommendation and IIS implements a compliant but non-recommended behavior. The biggest question that remains in my mind is the proper response to major version changes. What does it mean when the format of a message changes?= =20 Would it be possible for HTTP/2.0 to use, say, XML for its headers so that it's not even parseable by a HTTP/1.x implementation? If so, shouldn't a 1.x implementation always respond with 505 if the major version is higher than it understands? The new RTSP draft references RFC 2616, which in turn references RFC 2145.= =20 I assume all of the above will apply to it as well. Does everyone feel that the short reference to RFC 2616 in section 3.1 of the draft is sufficient? --=20 The nice thing about standards is that there are so many of them to choose =66rom. -- Andrew Tanenbaum --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/nq9fqznSmcYu2m8RAk/0AKCNxzIM3a5LQeZS5JItIeVa79XDfACcCVWu R25LY2tWwYGbtFIQT5p1dNE= =tNhB -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 15:43:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25150 for ; Tue, 28 Oct 2003 15:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagE-00009K-Bv for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKh6wk000551 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagE-00008e-4P for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25056 for ; Tue, 28 Oct 2003 15:42:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEagC-0006f2-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEagC-0006et-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagC-00006O-72; Tue, 28 Oct 2003 15:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEag5-0008WL-0M for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 15:42:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25023; Tue, 28 Oct 2003 15:42:45 -0500 (EST) Message-Id: <200310282042.PAA25023@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, 28 Oct 2003 15:42:45 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdpng-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: , --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 and Capability Negotiation Author(s) : D. Kutscher, J. Ott, C. Bormann Filename : draft-ietf-mmusic-sdpng-07.txt Pages : 65 Date : 2003-10-28 This document defines a language for describing multimedia sessions with respect to configuration parameters and capabilities of end systems. This document is a product of the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-07.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-sdpng-07.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-sdpng-07.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-10-28155650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdpng-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdpng-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155650.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 16:29:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25149 for ; Tue, 28 Oct 2003 15:43:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagE-00008x-73 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9SKh6sx000535 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagE-00008Y-1a for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 15:43:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25050 for ; Tue, 28 Oct 2003 15:42:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEagC-0006ex-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEagB-0006er-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 15:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEagB-00006C-KX; Tue, 28 Oct 2003 15:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEafy-0008Vb-5M for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 15:42:50 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25002; Tue, 28 Oct 2003 15:42:38 -0500 (EST) Message-Id: <200310282042.PAA25002@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, 28 Oct 2003 15:42:38 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-15.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 : SDP: Session Description Protocol Author(s) : M. Handley, V. Jacobson, C. Perkins Filename : draft-ietf-mmusic-sdp-new-15.txt Pages : 45 Date : 2003-10-28 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-15.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-new-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-15.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-10-28155616.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-28155616.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Oct 28 23:36:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23407 for ; Tue, 28 Oct 2003 23:36:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi40-0008IJ-G0 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 23:36:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T4a8uI031879 for mmusic-archive@odin.ietf.org; Tue, 28 Oct 2003 23:36:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi40-0008I6-CW for mmusic-web-archive@optimus.ietf.org; Tue, 28 Oct 2003 23:36:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23372 for ; Tue, 28 Oct 2003 23:35:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi3y-0000vw-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 23:36:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEi3x-0000vt-00 for mmusic-web-archive@ietf.org; Tue, 28 Oct 2003 23:36:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi3u-0008Gt-Qv; Tue, 28 Oct 2003 23:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEi3M-0008EQ-3j for mmusic@optimus.ietf.org; Tue, 28 Oct 2003 23:35:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23348 for ; Tue, 28 Oct 2003 23:35:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEi3J-0000v7-00 for mmusic@ietf.org; Tue, 28 Oct 2003 23:35:25 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AEi3J-0000un-00 for mmusic@ietf.org; Tue, 28 Oct 2003 23:35:25 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 28 Oct 2003 20:35:06 -0800 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.217] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Tue, 28 Oct 2003 20:35:06 -0800 (PST) Received: from sc8-sf-list2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Tue, 28 Oct 2003 20:32:02 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.13] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-list2.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 1AEi0m-0001td-00 for ; Tue, 28 Oct 2003 20:32:48 -0800 Date: Tue, 28 Oct 2003 20:31:13 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on scarface.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #106 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Mon, 27 Oct 2003 21:20:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-831553 ] Error in rfc2326bis-04 example 15.4 Bugs item #831553, was opened at 2003-10-28 05:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 Category: Editorial Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Error in rfc2326bis-04 example 15.4 Initial Comment: The last two messages in this example is: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=now- But I wonder how the receiver could perform the sync between RTP timestamp and NPT, without a RTP-Info header in the PLAY response? I wouldn't like to see such RTSP conversation in our applicatoin. A real implementation would likely to conduct the PLAY request/response including RTP-Info, for example: C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0 CSeq: 3 Session: 0456804596 Range: now- M->C: RTSP/1.0 200 OK CSeq: 3 Session: 0456804596 Range:npt=1000- RTP-Info: url=rtsp://live.example.com/concert/audio; seq=1473; rtptime=80000 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 02:17:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12807 for ; Wed, 29 Oct 2003 02:17:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkZm-0007oD-9D for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 02:17:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T7H68T030017 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 02:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkZl-0007nz-QD for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 02:17:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12369 for ; Wed, 29 Oct 2003 02:16:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkZh-00033w-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 02:17:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEkZg-00033s-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 02:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkZj-0007mb-8l; Wed, 29 Oct 2003 02:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEkZO-0007j7-2o for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 02:16:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12035; Wed, 29 Oct 2003 02:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEkZK-00033c-00; Wed, 29 Oct 2003 02:16:38 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AEkZJ-00033J-00; Wed, 29 Oct 2003 02:16:37 -0500 Received: from dynamicsoft.com ([63.113.46.68]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id h9T7G6ca007491; Wed, 29 Oct 2003 02:16:08 -0500 (EST) Message-ID: <3F9F6933.3010508@dynamicsoft.com> Date: Wed, 29 Oct 2003 02:16:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org, sipping Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Updated ICE 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks, I have submitted an update to ICE. Based on agreement at the last ietf, it is now a work item of MMUSIC. Until the I-D appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-00.txt http://www.jdrosen.net/papers/draft-ietf-mmusic-ice-00.html There were many changes since the last revision: * The draft is now SIP and offer/answer independent. The way I achieved this was to describe ICE as an abstract protocol, and then define mappings from that abstract protocol to concrete ones. A mapping is included for SIP, using the SDP alt parameter extension and Gonzalo's new IPV group semantic. * The spec now mandates that a client, in addition to be configured with one or more relay servers (i.e., turn), needs to know which of those are on the public internet. This would be through configuration. This information is needed only for backwards compatibility with non-ice clients. * In an update to TURN, I added a Send mechanism which allows relay of outbound requests. ICE now includes usage of this mechanism. Its needed for inter-enterprise calls where the media needs to pass through two relays, one in each domain. * I added some text on backwads compatibility processing when the caller realizes that the callee doesnt support ICE. * peer derived transport addresses learned by Sending (using the TURN Send primitive) a STUN request through a TURN relay have the same priority as turn derived transport addresses. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 03:47:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28600 for ; Wed, 29 Oct 2003 03:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElyu-0001u4-JW for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 03:47:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T8l8Yj007315 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 03:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElyt-0001te-KI for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 03:47:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28579 for ; Wed, 29 Oct 2003 03:46:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AElyp-0004PL-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 03:47:03 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AElyp-0004PI-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 03:47:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElyn-0001sw-Vq; Wed, 29 Oct 2003 03:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AElyA-0001pv-KY for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 03:46:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28559 for ; Wed, 29 Oct 2003 03:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEly7-0004Ow-00 for mmusic@ietf.org; Wed, 29 Oct 2003 03:46:20 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AEly7-0004Ot-00 for mmusic@ietf.org; Wed, 29 Oct 2003 03:46:19 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9T8kJSs015524 for ; Wed, 29 Oct 2003 09:46:20 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VXBS1NJB; Wed, 29 Oct 2003 09:46:19 +0100 Message-ID: <3F9F7E49.8030503@ericsson.com> Date: Wed, 29 Oct 2003 09:46:01 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Error in rfc2326bis-04 example 15.4 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, As Thomas has logged a bug about some examples, I like to point out that the examples has not been corrected to follow the specification text. Therefore I strongly suggest that people ignore the examples unless they are willing to send us complete proposals for how they should look. Thanks Thomas for the proposal for how to fix it, however I have a comment in regards to the example. See below: > Bugs item #831553, was opened at 2003-10-28 05:20 > Message generated for change (Tracker Item Submitted) made by Item Submitter > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=377744&aid=831553&group_id=23194 > > Category: Editorial > Group: None > Status: Open > Resolution: None > Priority: 5 > Submitted By: Thomas M Zeng (zengtm) > Assigned to: Nobody/Anonymous (nobody) > Summary: Error in rfc2326bis-04 example 15.4 > > Initial Comment: > The last two messages in this example is: > > C->M: PLAY rtsp://live.example.com/concert/audio > RTSP/1.0 > CSeq: 3 > Session: 0456804596 > > M->C: RTSP/1.0 200 OK > CSeq: 3 > Session: 0456804596 > Range:npt=now- > > > But I wonder how the receiver could perform the sync > between RTP timestamp and NPT, without a RTP-Info > header in the PLAY response? I wouldn't like to see > such RTSP conversation in our applicatoin. > > A real implementation would likely to conduct the PLAY > request/response including RTP-Info, for example: > > C->M: PLAY rtsp://live.example.com/concert/audio > RTSP/1.0 > CSeq: 3 > Session: 0456804596 > Range: now- > > M->C: RTSP/1.0 200 OK > CSeq: 3 > Session: 0456804596 > Range:npt=1000- > RTP-Info: > url=rtsp://live.example.com/concert/audio; seq=1473; > rtptime=80000 > Yes, it is correct that RTP-Info are need. However there are several options in this example: - Have a Range header in the Play request? - Should the server specify the current point since session start, or only give a now, which doesn't provide the client any reference to where in the live session the stream is in, but provides the minimum information about what is needed for synchronization. If you have any comments. Please respond. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 03:54:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28852 for ; Wed, 29 Oct 2003 03:54:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEm5b-00032w-Fn for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 03:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9T8s344011710 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 03:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEm5b-00032l-An for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 03:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28843 for ; Wed, 29 Oct 2003 03:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEm5Y-0004VR-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 03:54:00 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEm5Y-0004VO-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 03:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEm5a-000317-4a; Wed, 29 Oct 2003 03:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEm4n-0002vk-9R for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 03:53:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28818 for ; Wed, 29 Oct 2003 03:53:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEm4k-0004Us-00 for mmusic@ietf.org; Wed, 29 Oct 2003 03:53:10 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AEm4j-0004Up-00 for mmusic@ietf.org; Wed, 29 Oct 2003 03:53:09 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id h9T8rASs018184 for ; Wed, 29 Oct 2003 09:53:10 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id VXB82MCH; Wed, 29 Oct 2003 09:53:10 +0100 Message-ID: <3F9F7FE3.1080802@ericsson.com> Date: Wed, 29 Oct 2003 09:52:51 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf References: <200310281421.JAA22418@ietf.org> In-Reply-To: <200310281421.JAA22418@ietf.org> 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 would like to make you aware of that the 05 text versions contains a number of erroneous formatted tables. This is the known occurrences: Page 24, status codes. Page 26, table lines Page 51, Adjusted Packet diagram does not fit on one page. Page 62, 63, Header table. Page 99, Message syntax Page 100, 101, Message syntax page 114, Table 7, init state Page 115, Table 8, Ready State Page 116, Table 9, Play State You will have to live with these errors or read the pdf or PS version. Please note that the change bars in the documents are in relation to the 04 draft version. The major changes are in the methods chapter where a lot of rewrite has been performed. We will post a new corrected version after the meeting. Cheers Magnus Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : Real Time Streaming Protocol (RTSP) > Author(s) : H. Schulzrinne > Filename : draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf > Pages : 147 > Date : 2003-10-27 > > This memorandum is a revision of RFC 2326, which is currently a Pro- > posed Standard. > The Real Time Streaming Protocol, or RTSP, is an application-level > protocol for control over the delivery of data with real-time > properties. RTSP provides an extensible framework to enable con- > trolled, on-demand delivery of real-time data, such as audio and > video. Sources of data can include both live data feeds and stored > clips. This protocol is intended to control multiple data delivery > sessions, provide a means for choosing delivery channels such as UDP, > multicast UDP and TCP, and provide a means for choosing delivery > mechanisms based upon RTP (RFC 1889). > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mmusic-rfc2326bis-05.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 09:02:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07860 for ; Wed, 29 Oct 2003 09:02:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqtf-0000rN-2E for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 09:02:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TE23Pr003301 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 09:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqte-0000rA-V6 for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 09:02:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07762 for ; Wed, 29 Oct 2003 09:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqtd-000169-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 09:02:01 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEqtd-000165-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 09:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqtd-0000qZ-MO; Wed, 29 Oct 2003 09:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEqsw-0000mk-9R for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 09:01:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07675 for ; Wed, 29 Oct 2003 09:01:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEqsu-00014R-00 for mmusic@ietf.org; Wed, 29 Oct 2003 09:01:16 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AEqss-000149-00 for mmusic@ietf.org; Wed, 29 Oct 2003 09:01:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] RTSP transport negotiation Date: Wed, 29 Oct 2003 15:02:24 +0100 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> Thread-Topic: [MMUSIC] RTSP transport negotiation Thread-Index: AcOYXWWKlzWH1TSESiCj+B3UHCRHVwFxhAhQ From: "Enrico Balatti" To: "Geetha Srikantan" , Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Geetha, >... now change client IP address .... > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=3D client_port=3D8002-8003;server_port=3D9004-9005 > Range: npt=3D5- > Session: 12345678 I'm not sure the Range field can be aplicated to the SETUP request. From the specification it seems the Range is applicable on the SETUP = response but not in the SETUP request. Header Where Proxy DES OPT SETUP PLAY PAUSE TRD =20 Range R - - - o o - Range r - - c m* m* - Best Regards, Enrico ------------------------------------------------------------------ Ing Enrico M. Balatti CEFRIEL - Politecnico di Milano ICT Center of Excellence For Research, Innovation, Education & industrial Labs partnership via Fucini 2, 20133 Milano (ITALY) voice: +39 0223954327 fax: +39 0223954527 e-mail: balatti@cefriel.it www.cefriel.it = =20 ------------------------------------------------------------------ -----Original Message----- From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] Sent: mercoled=EC 22 ottobre 2003 7.26 To: mmusic@ietf.org Subject: [MMUSIC] RTSP transport negotiation Hello everyone, Here is the promised write-up on RTSP transport negotiation..sorry for the delay. If there is agreement on the content of this note, I can write up text for the RTSP draft. thanks geetha Topic: RTSP Transport negotiation using SETUP during play state. Introduction The RTSP specification allows for negotiation of transport parameters via the SETUP method, while the RTSP session is in play state. The transport parameters that can be negotiated and the exact form of this negotiation is under-specified in the RTSP documents. This note is an attempt to clarify some of the issues around transport negotiation for inclusion in the ongoing revision of RTSP. The recent interest in mobility for RTSP implementations also impacts transport parameters used by the session. For instance, a wireless RTSP client could be assigned a new IP address, or may experience change of network characteristics, while it is in the midst of a RTSP session. These issues are also addressed in this note. Outline: 1. Objective 2. Enumeration of all Transport Parameters 3. Transport Parameters Excluded from Negotiation 4. Negotiable Transport Parameters 5. Impact of Transport Negotiation 6. Examples 6.1 Client IP Address Changes 6.2 UDP -> TCP 6.3 TCP -> UDP 7. Other transport related changes to RTSP draft 8. Summary 1. Objective:=20 The main goals of this document are to * Provide an enumeration of transport parameters. * Identify transport parameters that cannot be negotiated with minimal impact on other sessions. * Propose transport parameters that can be negotiated during play state. * Determine implications of changing these parameters via a SETUP request while the session is in play state. * Provide examples demonstrating transport negotiation. 2. Enumeration of all Transport Parameters The following is a list of all transport parameters in the current RTSP draft. unicast/multicast destination source mode (=3DPLAY) interleaved layers (for multicast) ttl (for multicast port (for multicast) client_port (for RTP) server_port (for RTP) ssrc (for RTP) url 3. Transport Parameters Excluded from Negotiation It is recommended that the following parameters be excluded from the negotiation process. mode url unicast/multicast layers ttl ssrc destination source As the "mode" parameter is restricted to a single value in the current draft, it can be excluded. As per the recent proposal to not support addition of urls via SETUP during play state, the "url" parameter can be excluded.=20 Changing from multicast to unicast based on a single RTSP session's SETUP, would impact all the other clients accessing the multicast session.=20 Several issues need to be considered in this case, including transport negotiation. Similarly, changing from unicast to multicast also has implications beyond a single RTSP session. Changes to other multicast-related parameters, "layers", "ssrc", "ttl" most likely requires specification beyond transport negotiation. The recommendation is to *not* specify changing the transport from "unicast" to "multicast" or vice versa, and also not specify changes to the "layers" and "ttl" parameters, in this draft. It is recommedned=20 that negotiation of multicast-related transport parameters should be deferred to an RTSP-extension document.=20 Once an RTSP session has been initiated and the "destination" and "source" have been established - i.e. a multicast "destination" has been identified, and the stream "source" has been identified, there should be no need to change these parameters. It is recommended that the "destination" and "source" parameters not be negotiated when the session is in play state. The case of the client IP address change is signaled in a different manner, outlined in the next section. 4. Negotiable Transport Parameters Hence there are three main conditions that require transport negotiation for unicast: * client IP address changes * client wants to switch transport from UDP -> TCP=20 * client wants to switch transport from TCP -> UDP Changes in the client IP address can be indicated using a new "client_ip" parameter. Hence the parameters that are impacted by transport negotiation are: client_ip interleaved client_port server_port =20 5. Impact of Transport Negotiation The first column describes the primary change, the second and third columns describe any secondary transport parameters that MUST or=20 MAY change as a result of the primary change. Changed MUST MAY=09 ------- ---- --- =09 Client IP address client_ip client_port server_port UDP -> TCP interleaved Server may change Drop client_port interleaved channel ids Drop server_port in response. TCP -> UDP client_port in request client_ip server_port in response client_port in response=09 Drop interleaved 6. Examples 6.1 Client IP Address Changes C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 CSeq: 1 S->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 164 v=3D0 o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 s=3DRTSP Session i=3DAn Example of RTSP Session Usage a=3Dcontrol:rtsp://foo/twister t=3D0 0 m=3Daudio 0 RTP/AVP 0 a=3Dcontrol:rtsp://foo/twister/audio m=3Dvideo 0 RTP/AVP 26 a=3Dcontrol:rtsp://foo/twister/video C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=3D8000-8001 S->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;unicast;client_port=3D8000-8001; server_port=3D9000-9001 Session: 12345678 C->S: SETUP rtsp://foo/twister/video RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=3D8002-8003 Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=3D8002-8003; server_port=3D9004-9005 Session: 12345678 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 4 Range: npt=3D0- Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=3Drtsp://foo/twister/video; seq=3D9810092;rtptime=3D3450012, url=3Drtsp://foo/twister/audio;seq=3D5923;rtptime=3D22234432 Range: npt=3D0-30.76 ... now change client IP address .... C->S: SETUP rtsp://foo/twister/video RTSP/1.0 CSeq: 5 Transport: RTP/AVP;unicast;client_ip=3DC: RTSP/1.0 200 OK CSeq: 5 Transport: RTP/AVP;unicast;client_ip=3D; client_port=3D8002-8003;server_port=3D9004-9005 RTP-Info: url=3Drtsp://foo/twister/video; seq=3D;rtptime=3D, Range: npt=3D5-30.76 Session: 12345678 C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 6 Transport:RTP/AVP;unicast;client_ip=3D; client_port=3D8000-8001;server_port=3D9000-9001 Range: npt=3D5- Session: 12345678 S->C: RTSP/1.0 200 OK CSeq: 6 Transport: RTP/AVP;unicast;client_ip=3D; client_port=3D8000-8001;server_port=3D9000-9001 RTP-Info:url=3Drtsp://foo/twister/audio; seq=3D;rtptime=3D Range: npt=3D5-30.76=09 Session: 12345678 =20 6.2 UDP -> TCP C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 CSeq: 1 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Content-Length: 230 Content-Type: application/sdp Cseq: 1 v=3D0 o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 s=3DRTSP Session c=3DIN IP4 0.0.0.0 t=3D0 0 a=3Dcontrol:* a=3Drange:npt=3D0-10.566000 m=3Dvideo 0 RTP/AVP 26 a=3Dcontrol:rtsp://foo/twister/video m=3Daudio 0 RTP/AVP 0 a=3Dcontrol:rtsp://foo/twister/audio C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 S->C: RTSP/1.0 200 OK CSeq: 2 Session: 12345678 Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; server_port=3D9000-9001 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 3 Session: 12345678 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ CSeq: 3 RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D1339949552 Range: npt=3D0- Session: 12345678 ... now request TCP ... C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 4 Transport: RTP/AVP/TCP;interleaved=3D0-1 S->C: RTSP/1.0 200 OK Cseq: 4 Transport: RTP/AVP/TCP;unicast; client_ip=3D;interleaved=3D0-1 RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D Range: npt=3D0-10.56600 Session: 12345678 6.3 TCP -> UDP C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 CSeq: 1 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Content-Length: 230 Content-Type: application/sdp Cseq: 1 v=3D0 o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 s=3DRTSP Session c=3DIN IP4 0.0.0.0 t=3D0 0 a=3Dcontrol:* a=3Drange:npt=3D0-10.566000 m=3Dvideo 0 RTP/AVP 26 a=3Dcontrol:rtsp://foo/twister/video m=3Daudio 0 RTP/AVP 0 a=3Dcontrol:rtsp://foo/twister/audio C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP/TCP;interleaved=3D0-1 S->C: RTSP/1.0 200 OK Cseq: 2 Session: 12345678 Transport: RTP/AVP/TCP;unicast;client_ip=3D;interleaved=3D0-1 C->S: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 3 Session: 12345678 S->C: RTSP/1.0 200 OK Content-Base: rtsp://foo/twister/ Cseq: 3 RTP-Info: = url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D1339949552 Range: npt=3D0- Session: 12345678 ... now request UDP ... C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 4 Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 Range: npt=3D0- S->C: RTSP/1.0 200 OK CSeq: 4 Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; server_port=3D9000-9001 RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D Range: npt=3D0-10.56600 Session: 12345678 7. Other transport related changes to RTSP draft A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to transport parameters. (a) Section 13.40: Page 81: Are "src_addr" and "dest_addr" parameters going away? If these are relevant for NAT, perhaps they belong in the NAT document? Page 83-83: BNF indicates "client_port" and "server_port" will be indicated as 'port1-port2'. This doesn't seem adequate for the case where the RTP and RTCP ports are non-adjacent (per the new RTP spec rfc 3550).=20 Proposal: client_port: rtp=3D, rtcp=3D server_port: rtp=3D, rtcp=3D (b) Appendix B, B.1.1 Page 115: Mentions "src_addresses" and "dest_addresses" - what are these? Page 116: "non-continuous" ports - might want to rephrase to "non-adjacent" (or "non-continguous") ports? 8. Summary This note recommends negotiation of a few transport parameters and specifies mechanisms to do so. One new transport parameter "client_ip"=20 is recommended for use in cases where the client's IP address changes during the session.=20 It is also recommended that the client_port and server_port parameters be specified further with the use of tags "rtp_port" and "rtcp_port" to handle the case where these ports are non-contiguous. --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 10:45:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14757 for ; Wed, 29 Oct 2003 10:45:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsVB-0007Xd-PH for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 10:44:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TFirCx028989 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 10:44:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsVB-0007XU-MB for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 10:44:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14668 for ; Wed, 29 Oct 2003 10:44:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsV9-0003F0-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 10:44:51 -0500 Received: from sausage.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AEsQa-00036q-01 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 10:40:08 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AEsHo-00080U-LK for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 10:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsHm-0005TI-GR; Wed, 29 Oct 2003 10:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEsHY-0005Rt-Tt for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 10:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13916 for ; Wed, 29 Oct 2003 10:30:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEsHW-0002yg-00 for mmusic@ietf.org; Wed, 29 Oct 2003 10:30:46 -0500 Received: from mail.on2.com ([66.162.65.131] helo=on2.com) by ietf-mx with esmtp (Exim 4.12) id 1AEsHV-0002yd-00 for mmusic@ietf.org; Wed, 29 Oct 2003 10:30:46 -0500 Received: Received on2.com content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf Date: Wed, 29 Oct 2003 10:30:08 -0500 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf Thread-Index: AcOd+keZZXVdqwzRQBWDEmhHOqZsTAANuDVg From: "Matthew Heaney" To: "Magnus Westerlund" , X-MailScanner: Found to be clean Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Does the -05 version have a .pdf format? This URL doesn't work: I can only find the .txt file. > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 > Sent: Wednesday, October 29, 2003 3:53 AM > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D=20 > ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf >=20 >=20 > Hi, >=20 > I would like to make you aware of that the 05 text versions=20 > contains a=20 > number of erroneous formatted tables. This is the known occurrences: >=20 > Page 24, status codes. > Page 26, table lines > Page 51, Adjusted Packet diagram does not fit on one page. > Page 62, 63, Header table. > Page 99, Message syntax > Page 100, 101, Message syntax > page 114, Table 7, init state > Page 115, Table 8, Ready State > Page 116, Table 9, Play State >=20 > You will have to live with these errors or read the pdf or PS=20 > version.=20 > Please note that the change bars in the documents are in=20 > relation to the=20 > 04 draft version. The major changes are in the methods=20 > chapter where a=20 > lot of rewrite has been performed. >=20 > We will post a new corrected version after the meeting. >=20 > Cheers >=20 > Magnus >=20 > Internet-Drafts@ietf.org wrote: >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. This draft is a work item of the Multiparty Multimedia=20 > > Session Control Working Group of the IETF. > >=20 > > Title : Real Time Streaming Protocol (RTSP) > > Author(s) : H. Schulzrinne > > Filename : draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf > > Pages : 147 > > Date : 2003-10-27 > > =09 > > This memorandum is a revision of RFC 2326, which is=20 > currently a Pro-=20 > > posed Standard. The Real Time Streaming Protocol, or RTSP, is an=20 > > application-level protocol for control over the delivery of=20 > data with=20 > > real-time properties. RTSP provides an extensible framework=20 > to enable=20 > > con- trolled, on-demand delivery of real-time data, such as=20 > audio and > > video. Sources of data can include both live data feeds and stored > > clips. This protocol is intended to control multiple data delivery > > sessions, provide a means for choosing delivery channels=20 > such as UDP, > > multicast UDP and TCP, and provide a means for choosing delivery > > mechanisms based upon RTP (RFC 1889). > >=20 > > A URL for this Internet-Draft is:=20 > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.tx > > t > >=20 > > To remove yourself from the IETF Announcement list, send a=20 > message to > > ietf-announce-request with the word unsubscribe in the body=20 > of the message. > >=20 > > Internet-Drafts are also available by anonymous FTP. Login with the=20 > > username "anonymous" and a password of your e-mail address. After=20 > > logging in, type "cd internet-drafts" and then > > "get draft-ietf-mmusic-rfc2326bis-05.txt". > >=20 > > A list of Internet-Drafts directories can be found in=20 > > http://www.ietf.org/shadow.html or=20 > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >=20 > >=20 > > Internet-Drafts can also be obtained by e-mail. > >=20 > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt". > > =09 > > 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=20 > 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. > > =09 > > =09 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > Multimedia Technologies, Ericsson Research EAB/TVA/A > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Oct 29 14:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00597 for ; Wed, 29 Oct 2003 14:40:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwAr-00027D-FC for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 14:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TJe9wX008132 for mmusic-archive@odin.ietf.org; Wed, 29 Oct 2003 14:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwAp-00026y-P8 for mmusic-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 14:40:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00590 for ; Wed, 29 Oct 2003 14:39:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEwAn-0001Zq-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 14:40:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEwAm-0001Zn-00 for mmusic-web-archive@ietf.org; Wed, 29 Oct 2003 14:40:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwAk-00025m-UA; Wed, 29 Oct 2003 14:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEwA9-00021i-2t for mmusic@optimus.ietf.org; Wed, 29 Oct 2003 14:39:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00532; Wed, 29 Oct 2003 14:39:13 -0500 (EST) Message-Id: <200310291939.OAA00532@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: Wed, 29 Oct 2003 14:39:13 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-ice-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 : Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for the Session Initiation Protocol (SIP) Author(s) : J. Rosenberg Filename : draft-ietf-mmusic-ice-00.txt Pages : 37 Date : 2003-10-29 This document describes a methodology for Network Address Translator (NAT) traversal for multimedia session signaling protocols, such as the Session Initiation Protocol (SIP). This methodology is called Interactive Connectivity Establishment (ICE). ICE is not a new protocol, but rather makes use of existing protocols, such as Simple Traversal of UDP Through NAT (STUN), Traversal Using Relay NAT (TURN) and even Real Specific IP (RSIP). ICE works through the mutual cooperation of both endpoints in a session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-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-ice-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-ice-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-10-29150026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-ice-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-ice-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-29150026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 30 13:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04584 for ; Thu, 30 Oct 2003 13:43:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFHlD-0003WW-LI for mmusic-archive@odin.ietf.org; Thu, 30 Oct 2003 13:43:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UIh751013540 for mmusic-archive@odin.ietf.org; Thu, 30 Oct 2003 13:43:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFHlD-0003WJ-HM for mmusic-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 13:43:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04574 for ; Thu, 30 Oct 2003 13:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFHlB-00001J-00 for mmusic-web-archive@ietf.org; Thu, 30 Oct 2003 13:43:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFHlA-00001F-00 for mmusic-web-archive@ietf.org; Thu, 30 Oct 2003 13:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFHl6-0003U6-FY; Thu, 30 Oct 2003 13:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFHkz-0003Su-DZ for mmusic@optimus.ietf.org; Thu, 30 Oct 2003 13:42:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04568 for ; Thu, 30 Oct 2003 13:42:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFHkw-000019-00 for mmusic@ietf.org; Thu, 30 Oct 2003 13:42:50 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AFHkw-000015-00 for mmusic@ietf.org; Thu, 30 Oct 2003 13:42:50 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9UIgJUP005778 for ; Thu, 30 Oct 2003 10:42:19 -0800 (PST) Received: from sun.com (vpn-129-150-19-247.SFBay.Sun.COM [129.150.19.247]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HNL009ZF2MII8@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 30 Oct 2003 10:42:19 -0800 (PST) Date: Thu, 30 Oct 2003 13:40:16 -0500 From: Aravind Narasimhan Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf In-reply-to: To: Matthew Heaney Cc: mmusic@ietf.org Message-id: <3FA15B10.1080509@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4.1) Gecko/20031008 References: 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 only submitted the Postscript and the Text version as I was not aware until now that you could submit a PDF verison. You can however find the PDF version on RTSP.org at http://www.rtsp.org/drafts/ Aravind Matthew Heaney wrote: >Does the -05 version have a .pdf format? This URL doesn't work: > > > > >I can only find the .txt file. > > > > > >>-----Original Message----- >>From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] >>Sent: Wednesday, October 29, 2003 3:53 AM >>To: mmusic@ietf.org >>Subject: Re: [MMUSIC] I-D >>ACTION:draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf >> >> >>Hi, >> >>I would like to make you aware of that the 05 text versions >>contains a >>number of erroneous formatted tables. This is the known occurrences: >> >>Page 24, status codes. >>Page 26, table lines >>Page 51, Adjusted Packet diagram does not fit on one page. >>Page 62, 63, Header table. >>Page 99, Message syntax >>Page 100, 101, Message syntax >>page 114, Table 7, init state >>Page 115, Table 8, Ready State >>Page 116, Table 9, Play State >> >>You will have to live with these errors or read the pdf or PS >>version. >>Please note that the change bars in the documents are in >>relation to the >>04 draft version. The major changes are in the methods >>chapter where a >>lot of rewrite has been performed. >> >>We will post a new corrected version after the meeting. >> >>Cheers >> >>Magnus >> >>Internet-Drafts@ietf.org wrote: >> >> >> >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. This draft is a work item of the Multiparty Multimedia >>>Session Control Working Group of the IETF. >>> >>> Title : Real Time Streaming Protocol (RTSP) >>> Author(s) : H. Schulzrinne >>> Filename : draft-ietf-mmusic-rfc2326bis-05.txt,.ps,.pdf >>> Pages : 147 >>> Date : 2003-10-27 >>> >>>This memorandum is a revision of RFC 2326, which is >>> >>> >>currently a Pro- >> >> >>>posed Standard. The Real Time Streaming Protocol, or RTSP, is an >>>application-level protocol for control over the delivery of >>> >>> >>data with >> >> >>>real-time properties. RTSP provides an extensible framework >>> >>> >>to enable >> >> >>>con- trolled, on-demand delivery of real-time data, such as >>> >>> >>audio and >> >> >>>video. Sources of data can include both live data feeds and stored >>>clips. This protocol is intended to control multiple data delivery >>>sessions, provide a means for choosing delivery channels >>> >>> >>such as UDP, >> >> >>>multicast UDP and TCP, and provide a means for choosing delivery >>>mechanisms based upon RTP (RFC 1889). >>> >>>A URL for this Internet-Draft is: >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-05.tx >> >> >>>t >>> >>>To remove yourself from the IETF Announcement list, send a >>> >>> >>message to >> >> >>>ietf-announce-request with the word unsubscribe in the body >>> >>> >>of the message. >> >> >>>Internet-Drafts are also available by anonymous FTP. Login with the >>>username "anonymous" and a password of your e-mail address. After >>>logging in, type "cd internet-drafts" and then >>> "get draft-ietf-mmusic-rfc2326bis-05.txt". >>> >>>A list of Internet-Drafts directories can be found in >>>http://www.ietf.org/shadow.html or >>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >>> >>>Internet-Drafts can also be obtained by e-mail. >>> >>>Send a message to: >>> mailserv@ietf.org. >>>In the body type: >>> "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-05.txt". >>> >>>NOTE: The mail server at ietf.org can return the document in >>> MIME-encoded form by using the "mpack" utility. To use this >>> feature, insert the command "ENCODING mime" before the "FILE" >>> command. To decode the response(s), you will need "munpack" or >>> a MIME-compliant mail reader. Different MIME-compliant >>> >>> >>mail readers >> >> >>> exhibit different behavior, especially when dealing with >>> "multipart" MIME messages (i.e. documents which have been split >>> up into multiple messages), so check your local documentation on >>> how to manipulate these messages. >>> >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> >>-- >> >>Magnus Westerlund >> >>Multimedia Technologies, Ericsson Research EAB/TVA/A >>---------------------------------------------------------------------- >>Ericsson AB | Phone +46 8 4048287 >>Torshamsgatan 23 | Fax +46 8 7575550 >>S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Oct 30 15:03:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07771 for ; Thu, 30 Oct 2003 15:03:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ0e-0004dR-Pz for mmusic-archive@odin.ietf.org; Thu, 30 Oct 2003 15:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UK38AD017811 for mmusic-archive@odin.ietf.org; Thu, 30 Oct 2003 15:03:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ0e-0004dC-MP for mmusic-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 15:03:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07736 for ; Thu, 30 Oct 2003 15:02:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFJ0b-0001DU-00 for mmusic-web-archive@ietf.org; Thu, 30 Oct 2003 15:03:05 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFJ0b-0001DR-00 for mmusic-web-archive@ietf.org; Thu, 30 Oct 2003 15:03:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFJ0W-0004bG-MV; Thu, 30 Oct 2003 15:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFIzr-0004XW-Fl for mmusic@optimus.ietf.org; Thu, 30 Oct 2003 15:02:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07698; Thu, 30 Oct 2003 15:02:07 -0500 (EST) Message-Id: <200310302002.PAA07698@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, 30 Oct 2003 15:02:07 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-05.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 : A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) Author(s) : M. Westerlund Filename : draft-ietf-mmusic-sdp-bwparam-05.txt Pages : 20 Date : 2003-10-30 The existing Session Description Protocol (SDP) bandwidth modifiers and their values include the bandwidth needed also for the transport and IP layers. When using SDP with protocols like the Session Announcement Protocol (SAP), the Session Initiation Protocol (SIP) and the Real-Time Streaming Protocol (RTSP) and when the involved hosts reside in networks running different IP versions, the interpretation of what lower layer bandwidths are included is not clear. This document defines a bandwidth modifier that does not include transport overhead; instead an additional packet rate attribute is defined. The transport independent bit-rate value together with the maximum packet rate can then be used to calculate the real bit-rate over the transport actually used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-bwparam-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-bwparam-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-30150042.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bwparam-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-30150042.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Oct 31 13:44:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12773 for ; Fri, 31 Oct 2003 13:44:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeFj-0001uM-Ic for mmusic-archive@odin.ietf.org; Fri, 31 Oct 2003 13:44:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9VIi7iN007328 for mmusic-archive@odin.ietf.org; Fri, 31 Oct 2003 13:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeFi-0001u3-Lg for mmusic-web-archive@optimus.ietf.org; Fri, 31 Oct 2003 13:44:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12725 for ; Fri, 31 Oct 2003 13:43:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeFg-000527-00 for mmusic-web-archive@ietf.org; Fri, 31 Oct 2003 13:44:04 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFeFf-000522-00 for mmusic-web-archive@ietf.org; Fri, 31 Oct 2003 13:44:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeFf-0001ss-8y; Fri, 31 Oct 2003 13:44:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFeFW-0001rI-12 for mmusic@optimus.ietf.org; Fri, 31 Oct 2003 13:43:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12709 for ; Fri, 31 Oct 2003 13:43:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFeFT-00051k-00 for mmusic@ietf.org; Fri, 31 Oct 2003 13:43:51 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AFeFT-00051J-00 for mmusic@ietf.org; Fri, 31 Oct 2003 13:43:51 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9VIhJUR027717 for ; Fri, 31 Oct 2003 10:43:20 -0800 (PST) Received: from jamba (jamba.Eng.Sun.COM [129.146.124.115]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HNM00J8QXC771@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 31 Oct 2003 10:43:19 -0800 (PST) Date: Fri, 31 Oct 2003 10:43:41 -0800 From: Geetha Srikantan Subject: RE: [MMUSIC] RTSP transport negotiation In-reply-to: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> To: Enrico Balatti Cc: mmusic@ietf.org Message-id: <1067625819.5805.48.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain; charset=ISO-8859-1 References: <6F5FB8313FE82C4EA10DA4DA40B90949EC83D1@swing.cefriel.it> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nwkea-mail-1.sun.com id h9VIhJUR027717 Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable hi Enrico, Thanks for the comments.. That's true - per the current spec we cannot have a Range header in the SETUP request. However, if there were no Range header in the SETUP request during play state, the client would have to either=20 (a) send a PLAY request with a Range header and use the PLAY response=20 for synchronization, or, (b) live with the range selected by the server when it receives a SETUP=20 during play state. With (a) there is the issue of an extra PLAY request-response. It might just be better for the client to issue a PAUSE from the old transport setting, send a SETUP request to modify transport and PLAY to resume playing from the Range of the client's choosing. Here the transport negotiation happens in Ready state not Play state. With (b) there is a high likelihood of synchronization problems when transport parameters change - RTP packets would get delivered to the old transport, and discarded; the server has no way of knowing the gap in time between when it processes the SETUP during play and when the packets it already sent didn't actually get used by the player. This implies media glitches at the client are a real possibility. My inclination is to go with either specifying a Range header in the SETUP request during play state or send the SETUP request without Range, follow it up with a PLAY request with Range header. In the latter case we'd be violating another restriction in the spec about issuing PLAY requests during Play state, I believe. So this implies the spec would have to modify restrictions on either the SETUP request or the PLAY request. It would be good to get more comments on this, especially from the authors. thanks geetha On Wed, 2003-10-29 at 06:02, Enrico Balatti wrote: > Dear Geetha, >=20 > >... now change client IP address .... > > > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip=3D > client_port=3D8002-8003;server_port=3D9004-9005 > > Range: npt=3D5- > > Session: 12345678 >=20 >=20 > I'm not sure the Range field can be aplicated to the SETUP request. > From the specification it seems the Range is applicable on the SETUP re= sponse > but not in the SETUP request. >=20 > Header Where Proxy DES OPT SETUP PLAY PAUSE TRD =20 >=20 > Range R - - - o o - > Range r - - c m* m* - >=20 >=20 > Best Regards, > Enrico >=20 >=20 >=20 >=20 > ------------------------------------------------------------------ > Ing Enrico M. Balatti > CEFRIEL - Politecnico di Milano > ICT Center of Excellence For Research, Innovation, > Education & industrial Labs partnership > via Fucini 2, 20133 Milano (ITALY) > voice: +39 0223954327 fax: +39 0223954527 > e-mail: balatti@cefriel.it www.cefriel.it= =20 > ------------------------------------------------------------------ >=20 >=20 > -----Original Message----- > From: Geetha Srikantan [mailto:Geetha.Srikantan@Sun.COM] > Sent: mercoled=EC 22 ottobre 2003 7.26 > To: mmusic@ietf.org > Subject: [MMUSIC] RTSP transport negotiation >=20 >=20 > Hello everyone, >=20 > Here is the promised write-up on RTSP transport negotiation..sorry for > the delay. If there is agreement on the content of this note, I can > write up text for the RTSP draft. >=20 > thanks > geetha >=20 >=20 > Topic: RTSP Transport negotiation using SETUP during play state. >=20 > Introduction >=20 > The RTSP specification allows for negotiation of transport parameters > via the SETUP method, while the RTSP session is in play state. The > transport parameters that can be negotiated and the exact form of this > negotiation is under-specified in the RTSP documents. This note is an > attempt to clarify some of the issues around transport negotiation for > inclusion in the ongoing revision of RTSP. >=20 > The recent interest in mobility for RTSP implementations also impacts > transport parameters used by the session. For instance, a wireless > RTSP client could be assigned a new IP address, or may experience > change of network characteristics, while it is in the midst of a RTSP > session. These issues are also addressed in this note. >=20 >=20 > Outline: >=20 > 1. Objective > 2. Enumeration of all Transport Parameters > 3. Transport Parameters Excluded from Negotiation > 4. Negotiable Transport Parameters > 5. Impact of Transport Negotiation > 6. Examples > 6.1 Client IP Address Changes > 6.2 UDP -> TCP > 6.3 TCP -> UDP > 7. Other transport related changes to RTSP draft > 8. Summary >=20 >=20 >=20 > 1. Objective:=20 >=20 > The main goals of this document are to > * Provide an enumeration of transport parameters. > * Identify transport parameters that cannot be negotiated > with minimal impact on other sessions. > * Propose transport parameters that can be negotiated during > play state. > * Determine implications of changing these parameters via a > SETUP request while the session is in play state. > * Provide examples demonstrating transport negotiation. >=20 >=20 > 2. Enumeration of all Transport Parameters >=20 > The following is a list of all transport parameters in the current > RTSP draft. >=20 > unicast/multicast > destination > source > mode (=3DPLAY) > interleaved > layers (for multicast) > ttl (for multicast > port (for multicast) > client_port (for RTP) > server_port (for RTP) > ssrc (for RTP) > url >=20 >=20 > 3. Transport Parameters Excluded from Negotiation >=20 > It is recommended that the following parameters be excluded from the > negotiation process. >=20 > mode > url > unicast/multicast > layers > ttl > ssrc > destination > source >=20 >=20 > As the "mode" parameter is restricted to a single value in the > current draft, it can be excluded. >=20 > As per the recent proposal to not support addition of urls via SETU= P > during play state, the "url" parameter can be excluded.=20 >=20 > Changing from multicast to unicast based on a single RTSP session's > SETUP, would impact all the other clients accessing the multicast > session.=20 > Several issues need to be considered in this case, including transport > negotiation. Similarly, changing from unicast to multicast also has > implications beyond a single RTSP session. Changes to other > multicast-related parameters, "layers", "ssrc", "ttl" most likely > requires specification beyond transport negotiation. > The recommendation is to *not* specify changing the transport from > "unicast" to "multicast" or vice versa, and also not specify changes > to the "layers" and "ttl" parameters, in this draft. It is recommedned=20 > that negotiation of multicast-related transport parameters should be > deferred to an RTSP-extension document.=20 >=20 > Once an RTSP session has been initiated and the "destination" and > "source" have been established - i.e. a multicast "destination" has > been identified, and the stream "source" has been identified, there > should be no need to change these parameters. It is recommended that > the "destination" and "source" parameters not be negotiated when the > session is in play state. The case of the client IP address change is > signaled in a different manner, outlined in the next section. >=20 >=20 > 4. Negotiable Transport Parameters >=20 > Hence there are three main conditions that require transport > negotiation for unicast: >=20 > * client IP address changes > * client wants to switch transport from UDP -> TCP=20 > * client wants to switch transport from TCP -> UDP >=20 > Changes in the client IP address can be indicated using a new > "client_ip" parameter. Hence the parameters that are impacted by > transport negotiation are: >=20 > client_ip > interleaved > client_port > server_port >=20 > =20 > 5. Impact of Transport Negotiation >=20 > The first column describes the primary change, the second and third > columns describe any secondary transport parameters that MUST or=20 > MAY change as a result of the primary change. >=20 >=20 > Changed MUST MAY=09 > ------- ---- --- > =09 > Client IP address client_ip client_port > server_port >=20 > UDP -> TCP interleaved Server may change > Drop client_port interleaved channel ids > Drop server_port in response. >=20 > TCP -> UDP client_port in request client_ip > server_port in response client_port in response=09 > Drop interleaved >=20 >=20 >=20 > 6. Examples >=20 > 6.1 Client IP Address Changes >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 1 > Content-Type: application/sdp > Content-Length: 164 >=20 > v=3D0 > o=3D- 2890844256 2890842807 IN IP4 172.16.2.93 > s=3DRTSP Session > i=3DAn Example of RTSP Session Usage > a=3Dcontrol:rtsp://foo/twister > t=3D0 0 > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=3D8000-8001 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 > Session: 12345678 >=20 > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=3D8002-8003 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=3D8002-8003; > server_port=3D9004-9005 > Session: 12345678 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 4 > Range: npt=3D0- > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 4 > Session: 12345678 > RTP-Info: url=3Drtsp://foo/twister/video; > seq=3D9810092;rtptime=3D3450012, > url=3Drtsp://foo/twister/audio;seq=3D5923;rtptime=3D22234432 > Range: npt=3D0-30.76 >=20 > ... now change client IP address .... >=20 > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=3D client_port=3D8002-8003;server_port=3D9004-9005 > Range: npt=3D5- > Session: 12345678 > =09 > S->C: RTSP/1.0 200 OK > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=3D; > client_port=3D8002-8003;server_port=3D9004-9005 > RTP-Info: url=3Drtsp://foo/twister/video; > seq=3D;rtptime=3D, > Range: npt=3D5-30.76 > Session: 12345678 >=20 >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 6 > Transport:RTP/AVP;unicast;client_ip=3D; > client_port=3D8000-8001;server_port=3D9000-9001 > Range: npt=3D5- > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 6 > Transport: RTP/AVP;unicast;client_ip=3D; > client_port=3D8000-8001;server_port=3D9000-9001 > RTP-Info:url=3Drtsp://foo/twister/audio; > seq=3D;rtptime=3D > Range: npt=3D5-30.76=09 > Session: 12345678 >=20 >=20 >=20 > =20 > 6.2 UDP -> TCP >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 >=20 > v=3D0 > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > s=3DRTSP Session > c=3DIN IP4 0.0.0.0 > t=3D0 0 > a=3Dcontrol:* > a=3Drange:npt=3D0-10.566000 > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 >=20 > S->C: RTSP/1.0 200 OK > CSeq: 2 > Session: 12345678 > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > CSeq: 3 > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D13399= 49552 > Range: npt=3D0- > Session: 12345678 >=20 > ... now request TCP ... >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/TCP;interleaved=3D0-1 >=20 > S->C: RTSP/1.0 200 OK > Cseq: 4 > Transport: RTP/AVP/TCP;unicast; > client_ip=3D;interleaved=3D0-1 > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > Range: npt=3D0-10.56600 > Session: 12345678 >=20 >=20 >=20 > 6.3 TCP -> UDP >=20 > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 >=20 > v=3D0 > o=3D- 3262117360 3262117360 IN IP4 0.0.0.0 > s=3DRTSP Session > c=3DIN IP4 0.0.0.0 > t=3D0 0 > a=3Dcontrol:* > a=3Drange:npt=3D0-10.566000 > m=3Dvideo 0 RTP/AVP 26 > a=3Dcontrol:rtsp://foo/twister/video > m=3Daudio 0 RTP/AVP 0 > a=3Dcontrol:rtsp://foo/twister/audio >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/TCP;interleaved=3D0-1 >=20 > S->C: RTSP/1.0 200 OK > Cseq: 2 > Session: 12345678 > Transport: RTP/AVP/TCP;unicast;client_ip=3D;interleaved=3D= 0-1 >=20 > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 >=20 > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Cseq: 3 > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D7028;rtptime=3D13399= 49552 > Range: npt=3D0- > Session: 12345678 >=20 > ... now request UDP ... >=20 >=20 > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/UDP;unicast;client_port=3D8000-8001 > Range: npt=3D0- >=20 > S->C: RTSP/1.0 200 OK > CSeq: 4 > Transport: RTP/ACP/UDP;unicast;client_port=3D8000-8001; > server_port=3D9000-9001 > RTP-Info: url=3Drtsp://foo/twister/audio;seq=3D;rtptime=3D > Range: npt=3D0-10.56600 > Session: 12345678 >=20 >=20 >=20 >=20 > 7. Other transport related changes to RTSP draft >=20 > A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to > transport parameters. >=20 > (a) Section 13.40: > Page 81: Are "src_addr" and "dest_addr" parameters > going away? If these are relevant for NAT, perhaps they belong in > the NAT document? >=20 > Page 83-83: BNF indicates "client_port" and > "server_port" will be indicated as 'port1-port2'. This doesn't seem > adequate for the case where the RTP and RTCP ports are non-adjacent > (per the new RTP spec rfc 3550).=20 >=20 > Proposal: > client_port: rtp=3D, rtcp=3D > server_port: rtp=3D, rtcp=3D >=20 > (b) Appendix B, B.1.1 > Page 115: Mentions "src_addresses" and > "dest_addresses" - what are these? >=20 > Page 116: "non-continuous" ports - might want to rephrase to > "non-adjacent" (or "non-continguous") ports? >=20 >=20 >=20 > 8. Summary >=20 >=20 > This note recommends negotiation of a few transport parameters and > specifies mechanisms to do so. One new transport parameter "client_ip"=20 > is recommended for use in cases where the client's IP address changes > during the session.=20 >=20 > It is also recommended that the client_port and server_port parameters > be specified further with the use of tags "rtp_port" and "rtcp_port" > to handle the case where these ports are non-contiguous. --=20 Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic