From exim@www1.ietf.org Thu Apr 1 04:01:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02510 for ; Thu, 1 Apr 2004 04:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8y4L-0007CP-21 for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 04:01:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31911Lr027668 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 04:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8y4K-0007C6-Pn for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:01:00 -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 EAA02472 for ; Thu, 1 Apr 2004 04:00:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8y4I-0002Z3-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 04:00:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8y3P-0002Sk-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 04:00:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8y2T-0002Np-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 03:59:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8y2P-0006xN-Kk; Thu, 01 Apr 2004 03:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8y1S-0006tK-9i for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 03:58: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 DAA02340 for ; Thu, 1 Apr 2004 03:57:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8y1P-0002IW-00 for mmusic@ietf.org; Thu, 01 Apr 2004 03:57:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8y0U-0002EX-00 for mmusic@ietf.org; Thu, 01 Apr 2004 03:57:03 -0500 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1B8xzd-0002Am-00 for mmusic@ietf.org; Thu, 01 Apr 2004 03:56:09 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i318uAAh014721 for ; Thu, 1 Apr 2004 10:56:10 +0200 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 10:56:10 +0200 Received: from ericsson.com (sealwp01-14.sw.ericsson.se [153.88.142.14]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4TC8M; Thu, 1 Apr 2004 10:55:40 +0200 Message-ID: <406BD8E2.4070508@ericsson.com> Date: Thu, 01 Apr 2004 10:54:58 +0200 X-Sybari-Trust: 8e98e44f 2c4885b5 c2dda0f6 00000138 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: sv, en-us, en MIME-Version: 1.0 To: pkdutta@vsnl.net CC: mmusic@ietf.org Subject: Re: [MMUSIC] Delay in RTSP responses from Server References: <4de16b4db8a0.4db8a04de16b@vsnl.net> In-Reply-To: <4de16b4db8a0.4db8a04de16b@vsnl.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 08:56:10.0453 (UTC) FILETIME=[2D9ED050:01C417C7] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pranjal, I agree that the transfer of RTSP messages are important. To my understanding however there is nothing that prevents a client to use the available QoS mechanism, like INTServ or DIFFServ. Otherwise I think there is very little that you can do at RTSP level to mitigate such a problem depending on network congestion. However the server is responsible to ensure that it is not accepting more sessions than it can handle. There are also certain things a client can do, for example the STOP scenario you are presenting should not be obvious to a user. When the user presses PAUSE/STOP the client can freeze local playback immediately and take note of the NPT time. If it takes some time to get the response from the server, only waste network and server resources. So it is in fact only the cases where the client like something to start that will be obvious. I would also like to point out that after the first PLAY message, it is in most cases possible to synchronize the media for the new play range based on the already established synch between multiple media streams. The only thing that will not be accurate in such a scenario is the NPT of a certain media TS. Cheers Magnus pkdutta@vsnl.net wrote: > Hi, > I have developed a RTSP Client to interact with a VoD Server and it is streaming MPEG-2 Videos quite well. Sometimes I am observing delays in getting response for PLAY,PUASE,TEARDOWN messages from the Server. Assuming that the Server is responding intact under heavy loaded condition the source of the problem goes to the Network congestion. Under heavy video traffic when the network is overloaded there are chances that small RTSP Messages are getting lost(and so TCP retransmission at the Server will try sending again and again) and so there is a delay in getting response. Is there any already existing mechanism to implement End to end QoS mechanism for giving priority to RTSP Messages. Is there any already established method to overcome such problems. I feel RTSP Control messages are very important from a viewers perspective.Just thinking about a viewer who is not able to STOP the video for minutes!!! I will be very obliged with the valuable suggestions/comments. > > Thanks, > Pranjal > > > _______________________________________________ > 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 Thu Apr 1 04:48:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03582 for ; Thu, 1 Apr 2004 04:48:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8yno-000201-Oe for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 04:48:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i319m03p007686 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 04:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ynn-0001zn-Fh for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 04:47: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 EAA03558 for ; Thu, 1 Apr 2004 04:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ynj-0005q5-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 04:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8ymm-0005ll-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 04:46:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B8yls-0005hz-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 04: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 1B8ylt-0001rs-IH; Thu, 01 Apr 2004 04:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8ylr-0001rc-KI for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 04:45: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 EAA03538 for ; Thu, 1 Apr 2004 04:45:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8ylo-0005hU-00 for mmusic@ietf.org; Thu, 01 Apr 2004 04:45:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8yks-0005cU-00 for mmusic@ietf.org; Thu, 01 Apr 2004 04:44:59 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B8ykD-0005ZT-00 for mmusic@ietf.org; Thu, 01 Apr 2004 04:44:17 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i319iHYG024819 for ; Thu, 1 Apr 2004 11:44:17 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 11:44:17 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.102]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8F4TS8T; Thu, 1 Apr 2004 11:44:17 +0200 Message-ID: <406BE471.2020909@ericsson.com> Date: Thu, 01 Apr 2004 11:44:17 +0200 X-Sybari-Trust: 123d05e4 2c4885b5 c2dda0f6 00000138 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: sv, en-us, en MIME-Version: 1.0 To: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406A3409.4030705@sun.com> In-Reply-To: <406A3409.4030705@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 09:44:17.0426 (UTC) FILETIME=[E663EF20:01C417CD] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, See inline Geetha Srikantan wrote: > Magnus, > > I see your point of view on this, since you clarified your assumptions. > > In previous offline discussions there were discussions about how a RTSP > server would > maintain timing info for live streams. My confusion was centered around > that. > > I believe RTCP SR-based synchronization is possible, as you pointed > out..however it does > have some issues, as mentioned previously. > > Replying inline to some of the points in this mesage... > > > > Magnus Westerlund wrote: > >>> (b) Lost packets between live source and server, imply that the server >>> cannot accurately predict the next packet's sequence number. >> >> >> >> Also here I can't see the problem. The RTP sequence number indicates >> the first sequence number for a stream that the given synchronization >> information and time range applies for. Thus if one receives a RTP >> packet with a higher sequence number one knows that it is for the new >> range. >> >> A relay server that has received at least one packet can give this >> information that is valid even if a several RTP packets is lost before >> one gets forward. The client can't determine if the loss is between >> the relay or before. >> >> And if the server really has not received either the information from >> a upstream source or any RTP packet when responding, this value can be >> excluded. The RTP-Info header only requires either of the values to be >> present. > > > I did not realize that the RTP-Info header only requires either of the > values to be present. > I don't see it in section 14.33 of the draft..am I missing something? > Please review the ABNF, which specifies that at least one of the must be present. [snip] >> >>> Also the main purpose of the Range header is to map the NPT to >>> the RTP timestamp. As discussed above this mapping is not terribly >>> accurate in several live streaming scenarios. >> >> >> >> As I don't think it is any less accurate then for on-demand media I >> don't understand what the problem is. > > > I agree that RTCP SR-based mapping of NPT to TS is accurate..except that > this mapping > is not possible until an SR is received for each stream of the RTSP > session. > Sure, which depending on RTP profile, assigned RTCP SR bandwidth make vary significant from usage to usage. >>> If the live streams are part of a multicast session then there would >>> be an indication of the time when the session is active in the SDP, >>> however, with clock skews etc, it is diffcult to accurately pinpoint >>> the instantaneous time in the session. >> >> >> >> The instantaneous time is calculated based of the RTP timestamp for a >> given media and the mapping received by Range and RTP-Info between RTP >> timestamp and NPT at any point >> >> Example: >> >> Sync point >> -----|------------------------------------x------> t >> TS A B >> >> >> When one started the session one received by Range and RTP-Info the >> following information for RTP TS A. >> >> PLAY response: >> Range: npt=56.97- >> RTP-Info: url=; rtptime=164400 >> >> Thus A = 1644000 >> The media timestamp rate is 90kHz. >> >> The NPT time for B=465357 is: >> >> (465357-164400)/90000 + 56.97 = 60,3139666 s >> > This is fine as long as a non-zero and numeric Range header value exists. > In the case where the live source is not RTSP-aware, there is no Range > header available > and sync point A is effectively NPT=0, assuming the server started > accessing the live > session at A. Sure, in the above case the server can set its internal calculation mechanism at point A to 0. Then it would probably be best to give a npt=now- answer as it is not in the loop to the better timing. However even if a RTSP play has non numeric, i.e. npt=now- one can calculate the NPT from that point and forward. One can even use wall clock time and start counting it in relation to the start point. > >>> If the start time of the live session is not known, then 'npt=now-' >>> is the only reasonable value for the Range header in a PLAYresponse. >>> >> >> I agree that if one truly does not know the time since session start >> it is a viable operation. > > > You mean that npt=now- is acceptable in the Range header in this case, > right? > Yes. >> However all functionality exist to know the time. > > > Did you mean that the timestamp to NPT mapping is possible as you > described above? What I mean is that one can build solutions that do not have any of these problems as long as one uses the right mechanism. > >>> For this reason, it would be good to *not* require a Range header >>> other than 'Range: npt=now-' for live streams. >>> >> >> No, I think there are a lot of application that can benefit from >> presenting the original wall clock or time since session start. > > > As long as there is an understanding that the session start may not be > an accurate value, as in cases > where it is not known. I think that a server should present an accurate time or use npt=now-. > >>> Perhaps this could also be the mechanism to signal to the client that >>> this is a live stream and that it needs to perform stream >>> synchronization strictly via RTCP sender reports. >>> >> >> There are already text in there to indicate that the session has live >> qualities. There are already reasons why a client must support >> synchronization by RTCP. For example sender side clock skew >> corrections, multiple sources using different SSRCs, the possibility >> to exclude RTP-Info header. However the RTP-Info+Range header is a >> reliable transferred information. Although not guaranteed to be >> timely, it has a rather high probability to reach the client prior to >> any RTCP message. Also in most case it should reach the client prior >> to it finishing initial buffering, thus providing it with good initial >> synchronization for all media streams. > > > Yes, I agree that RTP-Info+Range can be helpful to the client since they > are transmitted over RTSP/TCP. > My point is that if there are inaccuracies in either RTP-Info or Range > because of unknown quantities like > session start time, missing packets, these need to be tolerated by clients. > I don't see how missing packets effects this at all. Session start time is either correctly forwarded by, live source, or first hand RTSP server, or it will not be correctly given. In which case I would recommend that one uses the npt=now- to indicate this. >>> Section 14.40, page 91: >>> ssrc: >>> The transport header in the server's response cannot populate the ssrc >>> for each stream, accurately in certain scenarios. >>> The source of the live stream may not be RTSP-aware, and the server >>> has to rely on RTP/RTCP to determine ssrc for each stream. >>> The server may have joined a multicast live session and receives, >>> say, one of the streams. >>> It also receives SETUP request from a client and needs to respond to >>> SETUP from a client, >>> before it sees the first packet of each stream. >>> Dropping the ssrc parameter from the Transport header in the SETUP >>> response would >>> simplify this case. >> >> >> >> It is possible to skip the SSRC, however not recommend as it indicates >> for which SSRC the synchronization information in RTP-Info applies to. >> Thus I would recommend that server awaits at least the first RTP >> packet to determine what SSRC is used for media distribution. > > > I am not convinced that the user experience is good when a server > refuses clients access to live sessions until > it has access to all the stream synchronization information. If the > server were to send RTP and RTCP packets, > without the RTP-Info or SSRC in RTSP responses, the client has an > opportunity to start decoding each stream > independently and perform inter-stream synchronization as soon as the > client receivess one RTCP SR per stream. > There is at least some media being rendered at the client, even if it is > not lip-sync'd etc. > As I wrote in the other mail I don't think this will occur frequently. In a well designed system using RTSP the synch information will be distributed using TCP, and will basically arrive as soon as possible. If there are problems delivering the RTSP response. A server waiting for the synchronization information can also use a 1xx code to tell that it is in fact waiting for the sync info. I would like to get some feedback from client implementors, it they really are willing start without synch and then try to do graceful fix of the synchronization when the information arrives. Also without giving the RTP-Info TS + Range it will be impossible to present accurate session position information. A client will only be able to calculate time since media delivery started. I think a lot of these discussion concerns issues that should be discussed in your streaming relay draft to achieve good performance and avoid these issues you are so concerned with. From a client perspective , I haven't seen a lot of need for clarifications. However I can look on how to further improve the discussion in the RTP appendix on synch. Otherwise I would recommend if you have specific concerns to present proposals for new text. Cheers Magnus -- 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 Apr 1 07:08:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07890 for ; Thu, 1 Apr 2004 07:08: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 1B90zN-0004KJ-Mn for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 07:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31C85J5016627 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 07:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90zN-0004K6-F4 for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:08: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 HAA07842 for ; Thu, 1 Apr 2004 07:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90zJ-0001jm-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90yP-0001al-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:07:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B90xW-0001VT-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:06:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90xO-0003pg-G6; Thu, 01 Apr 2004 07:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B90wU-0003mo-O7 for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 07:05: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 HAA07708 for ; Thu, 1 Apr 2004 07:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B90wQ-0001NH-00 for mmusic@ietf.org; Thu, 01 Apr 2004 07:05:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B90vW-0001J5-00 for mmusic@ietf.org; Thu, 01 Apr 2004 07:04:07 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1B90uu-0001FA-00 for mmusic@ietf.org; Thu, 01 Apr 2004 07:03:28 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i31C3SYG027748 for ; Thu, 1 Apr 2004 14:03:28 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 1 Apr 2004 11:11:10 +0200 Received: from ericsson.com (sealwp01-14.sw.ericsson.se [153.88.142.14]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FA8LDH; Thu, 1 Apr 2004 11:11:44 +0200 Message-ID: <406BDCAE.8090205@ericsson.com> Date: Thu, 01 Apr 2004 11:11:10 +0200 X-Sybari-Trust: 1b8d6363 2c4885b5 c2dda0f6 00000138 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: sv, en-us, en MIME-Version: 1.0 To: Geetha.Srikantan@Sun.COM CC: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406331DC.2080203@sun.com> <40642EB6.8030100@ericsson.com> <406A2C0A.4030302@sun.com> In-Reply-To: <406A2C0A.4030302@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Apr 2004 09:11:10.0367 (UTC) FILETIME=[4602CAF0:01C417C9] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, See inline. Geetha Srikantan wrote: > Magnus Westerlund wrote: >>> (a) That all live sources are RTSP-aware? >> >> >> >> No, but that the there is a root-distributor that is a RTSP server. >> The root RTSP server can be synchronized using either standard RTP >> means or any proprietary solution as this interface is not >> standardized. However it will be this RTSP root server that will be >> responsible giving the stream a NPT time, unless that is also provided >> through the interface between RTSP and the live source. > > > I was assuming the same thing. > >>> >>> (b) The server could maintain it's own RTP clock for each stream by >>> observing >>> the RTP timestamps of packets on each stream? >>> >> >> I don't see how that this would be necessary. If one has a RTSP server >> that receives a RTP + RTCP media stream. It will after listened to >> this for a few seconds received all necessary synchronization >> information. If this is not the root server and is only a relay it can >> use RTSP to receive the synchronization information for the media >> streams it is forwarding directly in RTSP. >> > This is an important point of concern. > I agree that an RTSP server, after it has received RTCP SR for each > stream, can map TS to NPT. > There are some issues though: > > 1. The server may not see RTCP SRs for all streams in the RTSP session > for several seconds, > because of (a) staggered transmission of RTCP SRs of each stream, (b) > lost SRs. > Since RTCP transmission intervals can be 5-10 seconds, this could be > 10-20 seconds or so. > > Now the server could either > (a) deny all client requests for the live session until it receives RTCP > SRs for all streams - even > though the server has RTP packets for all streams. This implies that > clients won't have access > to the live stream for several seconds after the session was requested. > OR > (b) respond to client requests without the RTP-Info header in PLAY > responses. > > If (a) and (b) are accepted as likely scenarios, then the clients cannot > expect to see a RTP-Info header > in PLAY responses, and should be able to handle the absence of the > RTP-Info header. However I don't see it likely that a relay RTSP server would need to rely on RTCP to establish the NPT binding. A relay will use the live sessions root RTSP sever or another RTSP relay. As it is using RTSP it can receive the RTP-Info and Range header which gives it all necessary information, unless things are sent using multiple SSRC, in which case RTP-Info at the delivery server still can't be used for synch. If the relay is slow on responding, I would still recommend that one wait for the synch info. Delivering things without synch does not make people happy. In conclusion I don't see a good reason why the delivery server would not have access to the synchronization information. > > 2. The server may not know when the live session started, for example if > it joins an ongoing > live session. > One option is for the server to assume NPT=0 at the time it receives RTP > packets from the > live source, and use that in synchronization mappings. So, the Range > header would have > this server-interpreted version of NPT. > But if the delivery server uses RTSP to request the media, it will receive this information. I would also like to point out that any delay of getting the synch information will only be present for the first user of a certain stream. Any user requesting a stream already delivered to the delivery server will be able to get correct information directly. >>> (c) The live source's transmission schedule for packets follows the >>> RTP timestamp clock? >>> That is, each succeeding packet's RTP timestamp will be equal to >>> or greater than all previous >>> packets, for that stream (modulo rollover)? >>> >> >> I am only assuming that this is a normal RTP media stream. Thus it can >> have backwards jump and other non-monotonic behaviour in the timestamp >> field. However I do expect that the RTP packets are sent in order, but >> not received by any relay in order. Thus a relay will be required to >> take certain care against reordering in the RTP-Info sequence number >> field. > > > Reordering and lost packets make it difficult to populate the sequence > number field of RTP-Info headers > for live streams. This is not the case for stored content. I think this > is a point worth noting for live streaming. > If the server has to guess about the next packet it is going to send, it > can't be a good thing. > I don't see how reordering creates any real problem. When a new user joins one takes the last sequence number received. Then in the RTP-Info one includes this number plus one. Then one forwards the next packet, it this was reordered an is in fact an older packet than what one claims in the RTP-Info, the client is able to detect that this packet is prior to the start of the stream. If there is packet loss or reorder that results in that the first packet that arrives to the client has sequence number much higher than the indicated one, it is okay. Because the only thing the RTP sequence number in the RTP-Info indicates is from what sequence number the request media stream is delivered. 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 Thu Apr 1 07:12:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08070 for ; Thu, 1 Apr 2004 07:12: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 1B913D-00050U-G0 for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 07:12:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CC3mX019242 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 07:12:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B913D-00050H-Ca for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:12: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 HAA07995 for ; Thu, 1 Apr 2004 07:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B913D-00029c-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B912B-00022s-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:11:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B911B-0001sf-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:09:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B911F-0004ee-7d; Thu, 01 Apr 2004 07:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8L1M-000190-GL for mmusic@optimus.ietf.org; Tue, 30 Mar 2004 10:19: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 KAA24675 for ; Tue, 30 Mar 2004 10:19:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8L1K-00023d-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:19:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8L0L-0001u7-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:18:18 -0500 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8KzM-0001cl-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:17:16 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 31 Mar 2004 02:21:49 +0530 Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2UFGKeu025115 for ; Tue, 30 Mar 2004 07:16:22 -0800 (PST) Received: from prdutta-w2k01.cisco.com ([10.77.138.207]) by codc-mira-1.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABZ37262; Tue, 30 Mar 2004 20:46:35 +0530 (IST) Message-Id: <4.3.2.7.2.20040330204055.0211b4b8@codc-mira-1.cisco.com> X-Sender: prdutta@codc-mira-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 20:46:34 +0530 To: mmusic@ietf.org From: "Pranjal Dutta (prdutta)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Delay in RTSP responses from 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I have developed a RTSP Client to interact with a VoD Server and it is streaming MPEG-2 Videos quite well. Sometimes I am observing delays in getting response for PLAY,PUASE,TEARDOWN messages from the Server. Assuming that the Server is responding intact under heavy loaded condition the source of the problem goes to the Network congestion. Under heavy video traffic when the network is overloaded there are chances that small RTSP Messages are getting lost(and so TCP retransmission at the Server will try sending again and again) and so there is a delay in getting response. Is there any already existing mechanism to implement End to end QoS mechanism for giving priority to RTSP Messages. Is there any already established method to overcome such problems. I feel RTSP Control messages are very important from a viewers perspective.Just thinking about a viewer who is not able to STOP the video for minutes!!! I will be very obliged with the valuable suggestions/comments. Thanks, Pranjal _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 1 07:12:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08087 for ; Thu, 1 Apr 2004 07:12:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B913E-00050k-5i for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 07:12:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31CC4hd019258 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 07:12:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B913E-00050X-1v for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 07:12: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 HAA07999 for ; Thu, 1 Apr 2004 07:12:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B913D-00029o-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B912D-000235-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:11:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B911C-0001uS-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 07:09:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B911G-0004gi-1l; Thu, 01 Apr 2004 07:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8L1U-0001CM-Ho for mmusic@optimus.ietf.org; Tue, 30 Mar 2004 10:19: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 KAA24708 for ; Tue, 30 Mar 2004 10:19:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B8L1S-00024d-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:19:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B8L0b-0001wJ-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:18:34 -0500 Received: from ind-iport-1-sec.cisco.com ([64.104.129.9] helo=ind-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B8L04-0001m0-00 for mmusic@ietf.org; Tue, 30 Mar 2004 10:18:01 -0500 Received: from india-core-1.cisco.com (64.104.129.221) by ind-iport-1.cisco.com with ESMTP; 31 Mar 2004 02:22:35 +0530 Received: from codc-mira-1.cisco.com (IDENT:mirapoint@codc-mira-1.cisco.com [192.122.173.20]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i2UFH2ew025157 for ; Tue, 30 Mar 2004 07:17:08 -0800 (PST) Received: from prdutta-w2k01.cisco.com ([10.77.138.207]) by codc-mira-1.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ABZ37306; Tue, 30 Mar 2004 20:47:16 +0530 (IST) Message-Id: <4.3.2.7.2.20040330204648.020df788@codc-mira-1.cisco.com> X-Sender: prdutta@codc-mira-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Mar 2004 20:47:15 +0530 To: mmusic@ietf.org From: "Pranjal Dutta (prdutta)" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Delay in RTSP responses from 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi, I have developed a RTSP Client to interact with a VoD Server and it is streaming MPEG-2 Videos quite well. Sometimes I am observing delays in getting response for PLAY,PUASE,TEARDOWN messages from the Server. Assuming that the Server is responding intact under heavy loaded condition the source of the problem goes to the Network congestion. Under heavy video traffic when the network is overloaded there are chances that small RTSP Messages are getting lost(and so TCP retransmission at the Server will try sending again and again) and so there is a delay in getting response. Is there any already existing mechanism to implement End to end QoS mechanism for giving priority to RTSP Messages. Is there any already established method to overcome such problems. I feel RTSP Control messages are very important from a viewers perspective.Just thinking about a viewer who is not able to STOP the video for minutes!!! I will be very obliged with the valuable suggestions/comments. Thanks, Pranjal _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 2 00:14:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10129 for ; Fri, 2 Apr 2004 00:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E62-0004my-9Z for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 21:07:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3227oe6018409 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 21:07:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9BAk-0003zz-NK for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 18:00:30 -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 SAA06441 for ; Thu, 1 Apr 2004 18:00:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9BAh-0006jO-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 18:00:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9B9s-0006ee-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 17:59:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9B9W-0006Yt-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 17:59:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B994U-0005jr-QZ; Thu, 01 Apr 2004 15:45:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95vl-0001qz-53 for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 12:24:41 -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 KAA17049 for ; Thu, 1 Apr 2004 10:39:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94Hj-00071e-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:39:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94Gl-0006x7-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:38:16 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1B94GH-0006rU-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:37:46 -0500 Received: from mangole ([130.209.247.112]:1417 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1B94Fk-0008DO-00; Thu, 01 Apr 2004 16:37:12 +0100 Date: Thu, 1 Apr 2004 16:38:23 +0100 From: Colin Perkins To: "Barany, Pete" Cc: mmusic@ietf.org, jo@tzi.uni-bremen.de Subject: Re: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt Message-Id: <20040401163823.6a6be5c3.csp@csperkins.org> In-Reply-To: <17D8F6DF3ED94D40BD607380866D9B7F327DB9@NAEX01.na.qualcomm.com> References: <17D8F6DF3ED94D40BD607380866D9B7F327DB9@NAEX01.na.qualcomm.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-portbld-freebsd4.9) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We're discussing a few minor issues that came up in the working group last call (mostly clarifying the IANA registration policies). You can expect an update shortly, which we expect to submit to the IESG for publication. Colin --> "Barany, Pete" writes: > Hi, > > What is the status of this Internet draft? Thanks. > > Regards, > > Pete > > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of > Colin Perkins > Sent: Tuesday, March 02, 2004 9:28 PM > To: mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de > Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdescriptions-03.txt > > This is to announce a working group last call on the SDP Security > Descriptions for Media Streams . > Please send any final comments on this draft to the MMUSIC mailing list > by 19th March 2004. > > If no substantive technical comments are received by that time, we will > request that this draft be published as a proposed standard RFC. > > -- > Colin Perkins > http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 2 03:14:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27979 for ; Fri, 2 Apr 2004 03:14: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 1B9EAN-0006bU-Mc for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 21:12:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322CJHu025376 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 21:12:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9C8p-0004QM-3R for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:02: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 TAA11317 for ; Thu, 1 Apr 2004 19:02:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9C8l-0005xc-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:02:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9C7h-0005ns-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:01:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9C6l-0005dG-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:00:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B99Zu-0000BG-86; Thu, 01 Apr 2004 16:18:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B96gu-0001mI-CM for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 13:13: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 NAA24526 for ; Thu, 1 Apr 2004 13:13:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B96gi-0000xo-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:13:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B96fo-0000tp-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:12:17 -0500 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1B96eu-0000on-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:11:20 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31IB9318818; Thu, 1 Apr 2004 21:11:09 +0300 (EET DST) X-Scanned: Thu, 1 Apr 2004 21:13:25 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i31IDPE0027817; Thu, 1 Apr 2004 21:13:25 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00j6J7rG; Thu, 01 Apr 2004 21:13:23 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i31IAks24458; Thu, 1 Apr 2004 21:10:46 +0300 (EET DST) Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 1 Apr 2004 21:10:12 +0300 Received: from agni.research.nokia.com (hed040-205.research.nokia.com [172.21.40.205]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id UAA16956; Thu, 1 Apr 2004 20:10:27 +0200 (EET) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i31I9foJ023941; Thu, 1 Apr 2004 21:09:41 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i31I9clf023940; Thu, 1 Apr 2004 21:09:38 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Magnus Westerlund Cc: Jae-Hwan Kim , "mmusic (E-mail)" Subject: Re: [MMUSIC] ETag Definition in draft-rfc2326bis-06 X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <4060728A.2010606@ericsson.com> (Magnus Westerlund's message of "Tue, 23 Mar 2004 18:23:22 +0100") References: <4060728A.2010606@ericsson.com> Date: Thu, 01 Apr 2004 21:09:38 +0300 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Apr 2004 18:10:12.0148 (UTC) FILETIME=[9336EF40:01C41814] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Magnus Westerlund writes: >Thanks for spotting this. I need some help with this as I have not a >complete understanding of how ETag is supposed to work. I understand that >they are server defined entities that only needs to follow the syntax. >So what I understand there is need for a RTSP header "ETag:" that can >be included in DESCRIBE and SETUP messages to be used to determine what >content the client actually wants to SETUP or question if the description is >up-to-date. I *think* that the idea is when you get an SDP from HTTP server or in response to DESCRIBE, you also get an a=etag. You then include the tag in the If-Match header of the SETUP request. If the tag is valid, the SETUP continues as usual. If the media resource has changed (or the tag is not valid for any other reason) the server should return 412. Now that ANNOUNCE/RECORD have been removed, I don't think we have any use of If-Match with DESCRIBE. According to RFC 2326, 304 is returned when a DESCRIBE or SETUP has an If-Modified-Since header. The Last-Modified/ If-Modified-Since mechanism is borrowed from HTTP/1.0. The description of 304 with ETag in bis-06, however, is pasted from HTTP/1.1. So, when you get a 304 response with ETag in HTTP/1.1? Lets suppose you have done GET and got 200 with the resource contents and ETag: "xyzzy". Later you send GET with If-None-Match: "xyzzy", if the server has not changed the resource it could respond with 304 and the ETag "xyzzy". When using the HTTP/1.1 entity tags there can multiple versions of the same resource, say, Swedish and Finnish web pages. The server could select a particular version based on the request (in this case, Accept-Language header in it). It would include a ETag and Content-Location headers in the response (probably also the Content-Language). A client (or proxy) could cache all the different versions. It can ask server if one of them is valid for a particular request by including all the cached ETags in the If-None-Match header of the GET request. The 304 response would then contain the ETag and Content-Location for the correct web page. So, I think options for bis-07 are: 1) deprecate If-Modified-Since and introduce If-None-Match 2) ditch ETag header in 304 and continue to use the current mix of HTTP/1.0 and HTTP/1.1 mechanisms >Having a ETag header in the describe response seem to have some >possibilities to clash with the SDP usage. In session >descriptions it seems much better to have the ETag in the >description so one does not have to add it if one for example >saves the SDP. Yes. However, I could imagine a "particular session description language" that does not have etag, so the ETag header would be needed. --Pekka >Jae-Hwan Kim wrote: >> Dear MMUSICers, >> Please look at the page 60 mentioning ETag header field. Basically, "304 >> Not modified" response is always supposed to have this >> header field. >> However, where is ETag definition in this spec.? >> In addition, when ETag is used in DESCRIBE response, should a client >> ignore this field? >> I found a commercial RTSP server had this field in the DESCRIBE >> response. >> TIA/BR, Jae-Hwan >> _______________________________________________ >> 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 Fri Apr 2 03:16:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28158 for ; Fri, 2 Apr 2004 03:16: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 1B9EBE-0007MH-Ec for mmusic-archive@odin.ietf.org; Thu, 01 Apr 2004 21:13:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i322DBQv028265 for mmusic-archive@odin.ietf.org; Thu, 1 Apr 2004 21:13:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CQD-0007ie-CH for mmusic-web-archive@optimus.ietf.org; Thu, 01 Apr 2004 19:20:33 -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 TAA13322 for ; Thu, 1 Apr 2004 19:20:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CQB-0000vj-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:20:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CPL-0000pc-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:19:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9COh-0000jA-00 for mmusic-web-archive@ietf.org; Thu, 01 Apr 2004 19:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9A9N-0007Qc-Fq; Thu, 01 Apr 2004 16:55:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B96no-0002Ay-MK for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 13:20:32 -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 NAA24687 for ; Thu, 1 Apr 2004 13:20:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B96nc-0001bb-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:20:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B96me-0001Wp-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:19:21 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx with esmtp (Exim 4.12) id 1B96lr-0001SG-00 for mmusic@ietf.org; Thu, 01 Apr 2004 13:18:31 -0500 Received: from esunmail ([129.147.156.34]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i31IIVwr003306 for ; Thu, 1 Apr 2004 11:18:31 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVI0015U86UAA@edgemail1.Central.Sun.COM> for mmusic@ietf.org; Thu, 01 Apr 2004 11:18:31 -0700 (MST) Received: from andrewlaptop ([209.128.69.139]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVI006NX86RXQ@mail.sun.net> for mmusic@ietf.org; Thu, 01 Apr 2004 11:18:30 -0700 (MST) Date: Thu, 01 Apr 2004 10:17:45 -0800 From: Andrew Large Subject: RE: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <406BDCAE.8090205@ericsson.com> To: "'Magnus Westerlund'" , geetha.srikantan@Sun.COM Cc: mmusic@ietf.org Message-id: <001301c41815$a284f9a0$6001a8c0@alarge.net> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Please forgive me for jumping into the middle of this, but this area is of considerable concern for us and I feel compelled to offer my $.02... First, Magnus, do I correctly capture your assertions? 1. The RTP-Info header need have only the "seq" or "rtptime" clauses, but not both. 2. For live streams, the server can provide "rtptime" values that are meaningful to a client, even in the absence of a meaningful Range header (e.g., when Range is "npt=now-"). 3. The server should always have access to stream synchronization information, so having the raw data necessary for generating the "rtptime" values shouldn't be an issue. If I have correctly captured your position above, I have a few questions/comments: a. [I apologize for not being on the list early enough to read the entire dialog] Are you conceding the point that the server may not know the sequence numbers of the first packets in each stream? b. When one populates the "seq" clause, how "close" does it have to be to the actual value? If it is acceptable to be off by some amount, could you provide some concrete parameters? Either by time or by sequence number value? (e.g., packet with given "seq" value must have RTP timestamp within 500ms of that of the first packet actually sent in that stream after the PLAY reply; or the first packet's sequence number must differ by no more than N). c. When one populates the "Range" header with a real value, what constraints are there (if any) on the relationship between that value and the first packets actually sent in each stream? For example, several servers simply report the value requested by the client and then start their streams with packets whose timestamps fall <= the value in the range header. In this case, the "rtptime" clause values in the RTP-Info header (which must map to the Range header) will be >= the RTP timestamps of the first packets actually received by the client. Note that this behavior is preferable to support (among other things), very long duration media samples. [If the reason for this is not clear, I'd be happy to follow up with an example] d. As a follow-up to [c], what constraints would there be on the "implicit" value for the Range header in a live stream where it is reported as "npt=now-", assuming that "rtptime" clauses are present in the RTP-Info header. For example, could the server pick some point, say, 5 minutes in the past as the synchronization point it will use to generate the "rtptime" clause values? e. One of the most common current scenarios for distributing a live broadcast is to have a "broadcaster" component that is *not* an RTSP server -- it simply generates an RTP stream to a pre-defined set of broadcast or unicast UDP ports and produces a ".sdp" file that describes the broadcast. The SDP file is staged in the media root of a full RTSP/RTP streaming server. When a client requests a session from the ".sdp", the server parses the *.sdp (which it may only become aware of at the point of the first client request) to figure out where it should "listen" for the streams (there is no RTSP dialog between the server and the broadcaster). In such a case, there is simply no way to guarantee that the server knows *either* sequence number *or* synchronization information for the streams before it needs to respond to the client. In theory, this is disallowed by the new draft of the spec, is it not? In practice, we (and others) have been using this method for years, and it works just fine, so long as the client does not insist on having the RTP-Info header. The client simply "resyncs" itself when the first SRs actually arrive in the data stream. I realize that we're working on a new mechanism (the relay work) that would have the broadcaster be an RTSP client and thus pass along the synchronization information when it "announces" the availability of the presentation, but do you really think we should be breaking an existing facility at the same time as we are introducing its replacement? f. Two editorial notes on the draft: + The separation of header syntax and sub-value discussion (ala NPT discussion) from the header descriptions is very confusing. It makes it quite difficult to get the full story on any one attribute of the specification (you end up having to simply search for keywords in the document, which is complicated in the case of RTP-Info because it shows up in several examples). + Maybe I just don't know how to parse the syntax properly, but it actually looks to me like the syntax asserts that the "seq" and "rtptime" values are in fact mutually exclusive -- you can only have one or the other (or is 1* supposed to be interpreted as "one or more"?) -- Andrew Large andrew.large@sun.com > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On > Behalf Of Magnus Westerlund > Sent: Thursday, April 01, 2004 1:11 AM > To: Geetha.Srikantan@sun.com > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming > > > Hi Geetha, > > See inline. > > Geetha Srikantan wrote: > > Magnus Westerlund wrote: > >>> (a) That all live sources are RTSP-aware? > >> > >> > >> > >> No, but that the there is a root-distributor that is a > RTSP server. > >> The root RTSP server can be synchronized using either standard RTP > >> means or any proprietary solution as this interface is not > >> standardized. However it will be this RTSP root server > that will be > >> responsible giving the stream a NPT time, unless that is > also provided > >> through the interface between RTSP and the live source. > > > > > > I was assuming the same thing. > > > >>> > >>> (b) The server could maintain it's own RTP clock for each > stream by > >>> observing > >>> the RTP timestamps of packets on each stream? > >>> > >> > >> I don't see how that this would be necessary. If one has a > RTSP server > >> that receives a RTP + RTCP media stream. It will after listened to > >> this for a few seconds received all necessary synchronization > >> information. If this is not the root server and is only a > relay it can > >> use RTSP to receive the synchronization information for the media > >> streams it is forwarding directly in RTSP. > >> > > This is an important point of concern. > > I agree that an RTSP server, after it has received RTCP SR for each > > stream, can map TS to NPT. > > There are some issues though: > > > > 1. The server may not see RTCP SRs for all streams in the > RTSP session > > for several seconds, > > because of (a) staggered transmission of RTCP SRs of each > stream, (b) > > lost SRs. > > Since RTCP transmission intervals can be 5-10 seconds, > this could be > > 10-20 seconds or so. > > > > Now the server could either > > (a) deny all client requests for the live session until it > receives RTCP > > SRs for all streams - even > > though the server has RTP packets for all streams. This > implies that > > clients won't have access > > to the live stream for several seconds after the session > was requested. > > OR > > (b) respond to client requests without the RTP-Info header in PLAY > > responses. > > > > If (a) and (b) are accepted as likely scenarios, then the > clients cannot > > expect to see a RTP-Info header > > in PLAY responses, and should be able to handle the absence of the > > RTP-Info header. > > However I don't see it likely that a relay RTSP server would need to > rely on RTCP to establish the NPT binding. A relay will use the live > sessions root RTSP sever or another RTSP relay. As it is > using RTSP it > can receive the RTP-Info and Range header which gives it all > necessary > information, unless things are sent using multiple SSRC, in > which case > RTP-Info at the delivery server still can't be used for synch. If the > relay is slow on responding, I would still recommend that one > wait for > the synch info. Delivering things without synch does not make people > happy. In conclusion I don't see a good reason why the > delivery server > would not have access to the synchronization information. > > > > > > 2. The server may not know when the live session started, > for example if > > it joins an ongoing > > live session. > > One option is for the server to assume NPT=0 at the time it > receives RTP > > packets from the > > live source, and use that in synchronization mappings. So, > the Range > > header would have > > this server-interpreted version of NPT. > > > > But if the delivery server uses RTSP to request the media, it will > receive this information. > > I would also like to point out that any delay of getting the synch > information will only be present for the first user of a > certain stream. > Any user requesting a stream already delivered to the delivery server > will be able to get correct information directly. > > >>> (c) The live source's transmission schedule for packets > follows the > >>> RTP timestamp clock? > >>> That is, each succeeding packet's RTP timestamp will > be equal to > >>> or greater than all previous > >>> packets, for that stream (modulo rollover)? > >>> > >> > >> I am only assuming that this is a normal RTP media stream. > Thus it can > >> have backwards jump and other non-monotonic behaviour in > the timestamp > >> field. However I do expect that the RTP packets are sent > in order, but > >> not received by any relay in order. Thus a relay will be > required to > >> take certain care against reordering in the RTP-Info > sequence number > >> field. > > > > > > Reordering and lost packets make it difficult to populate > the sequence > > number field of RTP-Info headers > > for live streams. This is not the case for stored content. > I think this > > is a point worth noting for live streaming. > > If the server has to guess about the next packet it is > going to send, it > > can't be a good thing. > > > > I don't see how reordering creates any real problem. When a new user > joins one takes the last sequence number received. Then in > the RTP-Info > one includes this number plus one. Then one forwards the next > packet, it > this was reordered an is in fact an older packet than what > one claims in > the RTP-Info, the client is able to detect that this packet > is prior to > the start of the stream. If there is packet loss or reorder > that results > in that the first packet that arrives to the client has > sequence number > much higher than the indicated one, it is okay. Because the > only thing > the RTP sequence number in the RTP-Info indicates is from > what sequence > number the request media stream is delivered. > > > 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 > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Apr 3 08:47:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21060 for ; Sat, 3 Apr 2004 08:47:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lU1-0008VS-7k for mmusic-archive@odin.ietf.org; Sat, 03 Apr 2004 08:46:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i33DknpV032699 for mmusic-archive@odin.ietf.org; Sat, 3 Apr 2004 08:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lU1-0008VK-2F for mmusic-web-archive@optimus.ietf.org; Sat, 03 Apr 2004 08:46:49 -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 IAA21025 for ; Sat, 3 Apr 2004 08:46:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9lTz-0007eq-00 for mmusic-web-archive@ietf.org; Sat, 03 Apr 2004 08:46:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9lT4-0007Wo-00 for mmusic-web-archive@ietf.org; Sat, 03 Apr 2004 08:45:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B9lSI-0007Pr-00 for mmusic-web-archive@ietf.org; Sat, 03 Apr 2004 08:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9lSH-0008Nh-BF; Sat, 03 Apr 2004 08:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B95LG-00011G-Vh for mmusic@optimus.ietf.org; Thu, 01 Apr 2004 11:46: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 KAA17297 for ; Thu, 1 Apr 2004 10:53:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B94VE-0000PH-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:53:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B94UE-0000JN-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:52:11 -0500 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 1B94TZ-0000Bo-00 for mmusic@ietf.org; Thu, 01 Apr 2004 10:51:30 -0500 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.30) for id 1B94T5-0005Gf-Jm; Thu, 01 Apr 2004 17:50:59 +0200 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Thu, 1 Apr 2004 17:50:58 +0200 (CEST) Received: from mail.tkn.tu-berlin.de ([130.149.49.80]) by mail.zrz.tu-berlin.de with esmtp (exim-4.30) for id 1B94T4-0005GL-M4; Thu, 01 Apr 2004 17:50:58 +0200 Received: from almathea.tkn.tu-berlin.de (almathea.tkn.TU-Berlin.DE [130.149.49.56]) by mail.tkn.tu-berlin.de (Postfix) with ESMTP id 5010C87368 for ; Thu, 1 Apr 2004 17:50:59 +0200 (CEST) Received: from karl by almathea.tkn.tu-berlin.de with local (Exim 3.35 #1 (Debian)) id 1B94T4-0002yf-00 for ; Thu, 01 Apr 2004 17:50:58 +0200 To: mmusic@ietf.org Message-Id: From: Holger Karl Date: Thu, 01 Apr 2004 17:50:58 +0200 X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Thu, 01 Apr 2004 17:50:58 +0200 Subject: [MMUSIC] Call for Papers: BASENETS '04 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Apologies if you receive multiple copies of this call! ---------------------------------------------------------------------- CALL FOR PAPERS ******************************************************** * * * 1st Workshop on Broadband Advanced Sensor Networks * * (co-located with BroadNets 04) * * San Jose, CA, October 2004 * * * * BASENETS 04 * * * ******************************************************** * * * http://www.basenets.org * * * ******************************************************** SCOPE The emergence and adoption of broadband wireless access standards, such as 802.16, 802.16a and 802.11a/g, offers exciting new possibilities for high-bandwidth data communication over the "last mile". A significant use of such high bandwidth may lie in the use of a variety of multimodal sensors for monitoring and control of diverse geographic areas. Such sensors may be used for remote video/audio surveillance and active monitoring of telemetry data in city blocks, highways, airports, hotels, campuses and a variety of other indoor and outdoor environments. This workshop is intended for the presentation and discussion of novel architectures, algorithms and applications of sensor networks based on the use of wireless broadband channels. Areas of interest include problems related to energy efficiency, dynamic control and reliability of such sensor network deployments, especially under the expected resource constraints on the sensor devices. Of particular interest are visions, practical case studies, demonstrations or pilots of innovative techniques for building sensor networks using either broadband local or metropolitan wireless networks. Topics of interest include, but are not limited to: * Multimedia Interfaces for Wireless Sensors * Broadband vs. Narrowband Wireless Sensing * Video and Audio Sensing Applications over Broadband Networks * Distributed Multimedia Compression/Aggregation for Broadband Sensor Networks * Scalability and Performance Bottlenecks for Wide-Area Broadband Sensing * Adaptive Configuration of Broadband Sensor Networks * Power and Spectrum Management Issues for Broadband Sensing * Architectures for Broadband Sensor Networks * Applications of Wireless Broadband Sensor Networks * Security and Privacy for Broadband Sensor Networks * Broadband Sensor Networks with Mobile Nodes * Heterogeneous Wired-Wireless Broadband Sensor Networks SUBMISSION Papers should be written in English, should not exceed 20 double-spaced, single-column pages, including figures and references, and should include an abstract, not to exceed 250 words. Papers should be submitted in PDF format via the EDAS system (http://edas.info). All papers will be peer reviewed. The best papers of this workshop will be considered for possible publication in the ACM Transactions on Sensor Networks (http://www.acm.org/tosn/). IMPORTANT DATES Full paper due: June 1, 2004 Notification of acceptance: July 12, 2004 Camera-ready copy: Aug. 9, 2004 Workshop Chairs: W. Heinzelman (U. of Rochester) B. Krishnamachari (U. of Southern California) Program Committee: N. Abu-Ghazaleh (Binghamton U.) J. Apostolopoulos (HP Labs) A. Bestavros (Boston U.) A. Campbell (Columbia U.) M. El Zarki (U. of California at Irvine) W.-C. Feng (OGI) S. Gupta (Arizona State U.) R. Han (U. of Colorado at Boulder) A. Helmy (U. of Southern California) S. Jha (U. of New South Wales) H. Karl (TU Berlin) M. Liu (U. of Michigan) B. Nath (Rutgers U.) M. Papadopouli (U. of North Carolina) A. Safwat (Queens U.) I. Stojmenovic (U. of Ottawa) U. Tureli (Stevens U.) M. van der Schaar (U. of California at Davis) P. Varshney (Syracuse U.) Publicity Chair: R. Han (U. of Colorado at Boulder) H. Karl (Technical University Berlin) For more details, please visit http://www.basenets.org or contact basenets04-chairs@ece.rochester.edu _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 01:23:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21418 for ; Thu, 8 Apr 2004 01:23: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 1BBS0K-0000uK-I1 for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 01:23:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i385N8Di003471 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 01:23:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBS0K-0000te-8z for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 01:23: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 BAA21264 for ; Thu, 8 Apr 2004 01:23:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBS0H-0006oV-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 01:23:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBPwb-0007iM-00 for mmusic-web-archive@ietf.org; Wed, 07 Apr 2004 23:11:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBO6g-0001lg-00 for mmusic-web-archive@ietf.org; Wed, 07 Apr 2004 21:13:26 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBNrn-0005l1-Az for mmusic-web-archive@ietf.org; Wed, 07 Apr 2004 20:58:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNrl-00052t-AI; Wed, 07 Apr 2004 20:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNrg-00052A-TC for mmusic@optimus.ietf.org; Wed, 07 Apr 2004 20:57:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26008 for ; Wed, 7 Apr 2004 20:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNre-00072V-00 for mmusic@ietf.org; Wed, 07 Apr 2004 20:57:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBLkS-00018u-00 for mmusic@ietf.org; Wed, 07 Apr 2004 18:42:21 -0400 Received: from ns2.packetvideo.com ([63.214.191.68]) by ietf-mx with esmtp (Exim 4.12) id 1BBKQm-0005Hj-00 for mmusic@ietf.org; Wed, 07 Apr 2004 17:17:56 -0400 Received: from misty.packetvideo.com ([209.120.169.42]) by ns2.packetvideo.com (8.12.10/8.12.10) with ESMTP id i37LHJoH059650; Wed, 7 Apr 2004 14:17:20 -0700 (PDT) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2657.72) id ; Wed, 7 Apr 2004 14:17:16 -0700 Message-ID: <72263E8E8622D611975C0002B32C19D805A180A1@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" , Geetha.Srikantan@Sun.COM Cc: mmusic@ietf.org Subject: RE: [MMUSIC] draft-rfc2326-06 comments wrt live streaming Date: Wed, 7 Apr 2004 14:17: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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Hi Geetha and Magnus: I have been reading this thread of discussion, and have some feedback for your reference. See inline. Cheers, -Thomas -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] Sent: Thursday, April 01, 2004 1:44 AM To: Geetha.Srikantan@Sun.COM Cc: mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming Hi Geetha, See inline Geetha Srikantan wrote: > Magnus, > > I see your point of view on this, since you clarified your assumptions. > > In previous offline discussions there were discussions about how a RTSP > server would > maintain timing info for live streams. My confusion was centered around > that. > > I believe RTCP SR-based synchronization is possible, as you pointed > out..however it does > have some issues, as mentioned previously. > > Replying inline to some of the points in this mesage... > [snip] >>> Section 14.40, page 91: >>> ssrc: >>> The transport header in the server's response cannot populate the ssrc >>> for each stream, accurately in certain scenarios. >>> The source of the live stream may not be RTSP-aware, and the server >>> has to rely on RTP/RTCP to determine ssrc for each stream. >>> The server may have joined a multicast live session and receives, >>> say, one of the streams. >>> It also receives SETUP request from a client and needs to respond to >>> SETUP from a client, >>> before it sees the first packet of each stream. >>> Dropping the ssrc parameter from the Transport header in the SETUP >>> response would >>> simplify this case. >> >> >> >> It is possible to skip the SSRC, however not recommend as it indicates >> for which SSRC the synchronization information in RTP-Info applies to. >> Thus I would recommend that server awaits at least the first RTP >> packet to determine what SSRC is used for media distribution. > > > I am not convinced that the user experience is good when a server > refuses clients access to live sessions until > it has access to all the stream synchronization information. If the > server were to send RTP and RTCP packets, > without the RTP-Info or SSRC in RTSP responses, [tz] Geetha: SSRC serves another purpose besides stream synchronization, and therefore without SSRC some players may not function well. Hence I second Magnus recommendation: server waits for the first RTP to get SSRC -- the delay is not that bad, right? Here are some more details: in our player (PacketVideo player) implementation, we use SSRC to filter out spurious packets on the RTP and RTCP receive port. Here is how it works: we record the SSRC in RTSP SETUP response; after we change to PLAYING state, we obtain RTP packets from our RTP receive port. We then filter the RTP packets by the expected SSRC. [tz] Here is how it helps: in wireless environment, it is not uncommon to have connections dropped due to bad channel conditions. Many a time player connects back and start a new session, but the OS happens to assign the same RTP receive port number. The server is not yet aware that previous session has been dropped (it needs to go through the timeout period waiting for RRs to come), and is sending both old session's RTP and new session's to the player. Filtering by SSRC helps the player to ignore unwanted RTP packets. > the client has an > opportunity to start decoding each stream > independently and perform inter-stream synchronization as soon as the > client receivess one RTCP SR per stream. > There is at least some media being rendered at the client, even if it is > not lip-sync'd etc. > As I wrote in the other mail I don't think this will occur frequently. In a well designed system using RTSP the synch information will be distributed using TCP, and will basically arrive as soon as possible. If there are problems delivering the RTSP response. A server waiting for the synchronization information can also use a 1xx code to tell that it is in fact waiting for the sync info. I would like to get some feedback from client implementors, it they really are willing start without synch and then try to do graceful fix of the synchronization when the information arrives. [tz] In the early days we (PacketVideo) did have a version of player that can start with neither RTP-Info information nor SR information. It assumes the first received RTP packet in video track is in synch with the first RTP packet in audio track, which is invalid if there are packets lost before the first one received, or that the sender do not send them in sych. So I am inclined to say that player can do it if the user can live with the degraded user experience in the beginning. Note that the player always has to check sychronization upon receiving timing information in SRs. [tz] Now a more interesting problem is for random positioning (as you touched upon below). It is well known that RTP-Info is required to handle PLAY after PAUSE (see a discussion thread a few months ago in this mailing list). Fortunately I have not seen customers asking for PAUSE in live streaming. But others might have. I don't know. Also without giving the RTP-Info TS + Range it will be impossible to present accurate session position information. A client will only be able to calculate time since media delivery started. I think a lot of these discussion concerns issues that should be discussed in your streaming relay draft to achieve good performance and avoid these issues you are so concerned with. From a client perspective , I haven't seen a lot of need for clarifications. However I can look on how to further improve the discussion in the RTP appendix on synch. Otherwise I would recommend if you have specific concerns to present proposals for new text. Cheers Magnus -- 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 Thu Apr 8 04:41:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20266 for ; Thu, 8 Apr 2004 04:41:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5e-0003h1-I7 for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 04:40:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i388eoOM014196 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 04:40:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5e-0003gt-9H for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 04:40: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 EAA20104 for ; Thu, 8 Apr 2004 04:40:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV5b-0005At-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 04:40:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSdQ-0005sn-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 02:03:33 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRK1-0007gj-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:39:25 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRJd-0006lm-Lu for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRJd-00089S-4A; Thu, 08 Apr 2004 00:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRJA-0007zv-QC for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 00:38: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 AAA14523 for ; Thu, 8 Apr 2004 00:38:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRJ8-0007bQ-00 for mmusic@ietf.org; Thu, 08 Apr 2004 00:38:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOkD-0000VE-00 for mmusic@ietf.org; Wed, 07 Apr 2004 21:54:19 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1BBNVC-0003Fd-00 for mmusic@ietf.org; Wed, 07 Apr 2004 20:34:42 -0400 Received: from phys-mpk-2 ([129.146.11.82]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i380YCgx010509 for ; Wed, 7 Apr 2004 17:34:12 -0700 (PDT) Received: from sun.com (jamba.SFBay.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 <0HVT00491TKZTL@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 07 Apr 2004 17:34:12 -0700 (PDT) Date: Wed, 07 Apr 2004 17:34:56 -0700 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <72263E8E8622D611975C0002B32C19D805A180A1@misty.packetvideo.com> To: Thomas Zeng , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <40749E30.8050503@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <72263E8E8622D611975C0002B32C19D805A180A1@misty.packetvideo.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Thomas, Thanks for the feedback and notes about client side issues. Replying inline... Thomas Zeng wrote: >>>It is possible to skip the SSRC, however not recommend as it indicates >>>for which SSRC the synchronization information in RTP-Info applies to. >>>Thus I would recommend that server awaits at least the first RTP >>>packet to determine what SSRC is used for media distribution. >>> >>> >>I am not convinced that the user experience is good when a server >>refuses clients access to live sessions until >>it has access to all the stream synchronization information. If the >>server were to send RTP and RTCP packets, >>without the RTP-Info or SSRC in RTSP responses, >> >> > >[tz] Geetha: SSRC serves another purpose besides stream synchronization, and >therefore without SSRC some players may not function well. Hence I second >Magnus recommendation: server waits for the first RTP to get SSRC -- the >delay is not that bad, right? Here are some more details: in our player >(PacketVideo player) implementation, we use SSRC to filter out spurious >packets on the RTP and RTCP receive port. Here is how it works: we record >the SSRC in RTSP SETUP response; after we change to PLAYING state, we obtain >RTP packets from our RTP receive port. We then filter the RTP packets by the >expected SSRC. >[tz] Here is how it helps: in wireless environment, it is not uncommon to >have connections dropped due to bad channel conditions. Many a time player >connects back and start a new session, but the OS happens to assign the same >RTP receive port number. The server is not yet aware that previous session >has been dropped (it needs to go through the timeout period waiting for RRs >to come), and is sending both old session's RTP and new session's to the >player. Filtering by SSRC helps the player to ignore unwanted RTP packets. > > This looks like a good use case for having the SSRC in the SETUP response's Transport header. Thanks for providing the details. I'm less concerned about delays caused by the SETUP response, than by PLAY response. >>the client has an >>opportunity to start decoding each stream >>independently and perform inter-stream synchronization as soon as the >>client receivess one RTCP SR per stream. >>There is at least some media being rendered at the client, even if it is >>not lip-sync'd etc. >> >> >> > >As I wrote in the other mail I don't think this will occur frequently. >In a well designed system using RTSP the synch information will be >distributed using TCP, and will basically arrive as soon as possible. If >there are problems delivering the RTSP response. > >A server waiting for the synchronization information can also use a 1xx >code to tell that it is in fact waiting for the sync info. > >I would like to get some feedback from client implementors, it they >really are willing start without synch and then try to do graceful fix >of the synchronization when the information arrives. > >[tz] In the early days we (PacketVideo) did have a version of player that >can start with neither RTP-Info information nor SR information. It assumes >the first received RTP packet in video track is in synch with the first RTP >packet in audio track, which is invalid if there are packets lost before the >first one received, or that the sender do not send them in sych. So I am >inclined to say that player can do it if the user can live with the degraded >user experience in the beginning. Note that the player always has to check >sychronization upon receiving timing information in SRs. > > Ok.. >[tz] Now a more interesting problem is for random positioning (as you >touched upon below). It is well known that RTP-Info is required to handle >PLAY after PAUSE (see a discussion thread a few months ago in this mailing >list). Fortunately I have not seen customers asking for PAUSE in live >streaming. But others might have. I don't know. > > > Live sessions can't be PAUSED, right? So this shouldn't be an issue.. geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 04:41:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20428 for ; Thu, 8 Apr 2004 04:41:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5z-0003py-S4 for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 04:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i388fBsD014738 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 04:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5z-0003pX-N4 for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 04:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20237 for ; Thu, 8 Apr 2004 04:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV5w-0005F7-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 04:41:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSe3-0005zQ-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 02:04:13 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRKA-0007gj-02 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:39:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRDz-0006Tq-H7 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:33:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBR5W-00033k-N4; Thu, 08 Apr 2004 00:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBQJD-0001g4-Ou for mmusic@optimus.ietf.org; Wed, 07 Apr 2004 23:34: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 XAA12010 for ; Wed, 7 Apr 2004 23:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBQJB-0001vI-00 for mmusic@ietf.org; Wed, 07 Apr 2004 23:34:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOMg-0004gy-00 for mmusic@ietf.org; Wed, 07 Apr 2004 21:30:01 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BBMqr-000752-00 for mmusic@ietf.org; Wed, 07 Apr 2004 19:53:01 -0400 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i37Nq3Vo029335 for ; Wed, 7 Apr 2004 17:52:04 -0600 (MDT) Received: from sun.com (jamba.SFBay.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 <0HVT00J9PRO7QW@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 07 Apr 2004 16:52:55 -0700 (PDT) Date: Wed, 07 Apr 2004 16:53:40 -0700 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <406BDCAE.8090205@ericsson.com> To: Magnus Westerlund , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <40749484.7070107@sun.com> Organization: Sun Microsystems 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 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406331DC.2080203@sun.com> <40642EB6.8030100@ericsson.com> <406A2C0A.4030302@sun.com> <406BDCAE.8090205@ericsson.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Magnus, Replying inline.. Magnus Westerlund wrote: >> This is an important point of concern. >> I agree that an RTSP server, after it has received RTCP SR for each >> stream, can map TS to NPT. >> There are some issues though: >> >> 1. The server may not see RTCP SRs for all streams in the RTSP >> session for several seconds, >> because of (a) staggered transmission of RTCP SRs of each stream, >> (b) lost SRs. >> Since RTCP transmission intervals can be 5-10 seconds, this could >> be 10-20 seconds or so. >> >> Now the server could either >> (a) deny all client requests for the live session until it receives >> RTCP SRs for all streams - even >> though the server has RTP packets for all streams. This implies that >> clients won't have access >> to the live stream for several seconds after the session was requested. >> OR >> (b) respond to client requests without the RTP-Info header in PLAY >> responses. >> >> If (a) and (b) are accepted as likely scenarios, then the clients >> cannot expect to see a RTP-Info header >> in PLAY responses, and should be able to handle the absence of the >> RTP-Info header. > > > However I don't see it likely that a relay RTSP server would need to > rely on RTCP to establish the NPT binding. A relay will use the live > sessions root RTSP sever or another RTSP relay. As it is using RTSP it > can receive the RTP-Info and Range header which gives it all necessary > information, unless things are sent using multiple SSRC, in which case > RTP-Info at the delivery server still can't be used for synch. If the > relay is slow on responding, I would still recommend that one wait for > the synch info. Delivering things without synch does not make people > happy. In conclusion I don't see a good reason why the delivery server > would not have access to the synchronization information. > Synchronization info is not always available when the origin/tier 1 RTSP server *starts* receiving RTP streams from the live source. If the origin server is not to handle any requests for this live session, then relay servers requesting this content will be stalled. That was my point. I realize that when all servers have synchronization info available based on RTCP SRs or RTP-Info/Range headers, a server can respond with the rtptime value for current wallclock time. >> 2. The server may not know when the live session started, for example >> if it joins an ongoing >> live session. >> One option is for the server to assume NPT=0 at the time it receives >> RTP packets from the >> live source, and use that in synchronization mappings. So, the Range >> header would have >> this server-interpreted version of NPT. >> > > But if the delivery server uses RTSP to request the media, it will > receive this information. > > I would also like to point out that any delay of getting the synch > information will only be present for the first user of a certain > stream. Any user requesting a stream already delivered to the delivery > server will be able to get correct information directly. From my experience, in live sessions, there are hundreds of clients trying to connect and receive the live session within a few seconds of each other. So if the streaming server joins a live session and waits to receive synchronization info before it responds to any client, all of these clients would have to wait. It's a tradeoff between (a) clients waiting for RTSP PLAY response, (b) clients receiving PLAY response without synchronization info, decoding RTP streams right away and performing delayed synchronization. Many of us have opted for (b) in implementations (as Andrew Large mentions in his email). >> Reordering and lost packets make it difficult to populate the >> sequence number field of RTP-Info headers >> for live streams. This is not the case for stored content. I think >> this is a point worth noting for live streaming. >> If the server has to guess about the next packet it is going to send, >> it can't be a good thing. >> > > I don't see how reordering creates any real problem. When a new user > joins one takes the last sequence number received. Then in the > RTP-Info one includes this number plus one. Then one forwards the next > packet, it this was reordered an is in fact an older packet than what > one claims in the RTP-Info, the client is able to detect that this > packet is prior to the start of the stream. If there is packet loss or > reorder that results in that the first packet that arrives to the > client has sequence number much higher than the indicated one, it is > okay. Because the only thing the RTP sequence number in the RTP-Info > indicates is from what sequence number the request media stream is > delivered. I can see that this would work, however it seems like you are recommending that a server 'guess' about the sequence number of the next packet it sends, since the server cannot accurately pinpoint the exact sequence number of the next packet it sends. It might be preferable to interpret 'seqno ' as the sequence number of the packet last sent by the server, so the client knows to look for sequence numbers higher than that. > Cheers > > Magnus Westerlund geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 04:41:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20423 for ; Thu, 8 Apr 2004 04:41:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5z-0003px-S6 for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 04:41:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i388fBF2014734 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 04:41:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBV5z-0003pY-Mq for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 04:41:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20236 for ; Thu, 8 Apr 2004 04:41:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBV5w-0005F2-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 04:41:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBSe2-0005zG-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 02:04:12 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBRKA-0007gj-01 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:39:34 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBRE0-0006Tt-2x for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 00:33:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBR6A-0003VH-HO; Thu, 08 Apr 2004 00:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBQsI-0001Cx-1M for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 00:10:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13387 for ; Thu, 8 Apr 2004 00:10:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBQsF-0004uo-00 for mmusic@ietf.org; Thu, 08 Apr 2004 00:10:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBOWe-0006Jj-00 for mmusic@ietf.org; Wed, 07 Apr 2004 21:40:17 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BBNA7-00011O-00 for mmusic@ietf.org; Wed, 07 Apr 2004 20:12:55 -0400 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i380BvVs007830 for ; Wed, 7 Apr 2004 18:11:58 -0600 (MDT) Received: from sun.com (jamba.SFBay.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 <0HVT004TASLETL@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Wed, 07 Apr 2004 17:12:52 -0700 (PDT) Date: Wed, 07 Apr 2004 17:13:36 -0700 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <406BE471.2020909@ericsson.com> To: Magnus Westerlund , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <40749930.2000802@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <405B347B.3060602@sun.com> <40605F48.9030001@ericsson.com> <406A3409.4030705@sun.com> <406BE471.2020909@ericsson.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Magnus, Thanks for the pointer to the ABNF - yes it clarifies that RTP-Info can have either seqno *or* rtptime. I guess we agree that Range: npt=now- is acceptable in the PLAY response, when accurate NPT value is not known. My comment was about missing packets impacting seqno in the RTP-Info header is covered in the previous email, so I'll skip it here. Replying inline to the rest. Magnus Westerlund wrote: >> I am not convinced that the user experience is good when a server >> refuses clients access to live sessions until >> it has access to all the stream synchronization information. If the >> server were to send RTP and RTCP packets, >> without the RTP-Info or SSRC in RTSP responses, the client has an >> opportunity to start decoding each stream >> independently and perform inter-stream synchronization as soon as the >> client receivess one RTCP SR per stream. >> There is at least some media being rendered at the client, even if it >> is not lip-sync'd etc. >> > > As I wrote in the other mail I don't think this will occur frequently. > In a well designed system using RTSP the synch information will be > distributed using TCP, and will basically arrive as soon as possible. > If there are problems delivering the RTSP response. > > A server waiting for the synchronization information can also use a > 1xx code to tell that it is in fact waiting for the sync info. > > I would like to get some feedback from client implementors, it they > really are willing start without synch and then try to do graceful fix > of the synchronization when the information arrives. Also without > giving the RTP-Info TS + Range it will be impossible to present > accurate session position information. A client will only be able to > calculate time since media delivery started. As I mentioned in the previous email, it's a tradeoff between the client waiting for the RTSP handshake to complete and the client waiting for RTCP SRs, while it plays out individual streams. In the first case no media is rendered at the client until it completes the RTSP handshake and receives RTP. > I think a lot of these discussion concerns issues that should be > discussed in your streaming relay draft to achieve good performance > and avoid these issues you are so concerned with. From a client > perspective , I haven't seen a lot of need for clarifications. However > I can look on how to further improve the discussion in the RTP > appendix on synch. Otherwise I would recommend if you have specific > concerns to present proposals for new text. We are working on a revision of the relay draft and will cover these issues there. However, I'd like to point out that the live streaming issues do occur with or without relays, so they need to be addressed in the main spec. Sure, I will work on proposing some text to clarify these issues and send it to the alias. > Cheers > > Magnus > thanks geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 13:37:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06838 for ; Thu, 8 Apr 2004 13:37:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdSE-0003xj-JJ for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 13:36:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38Hag0M015232 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 13:36:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdSE-0003xW-Bg for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 13:36:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06737 for ; Thu, 8 Apr 2004 13:36:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdSB-0004DN-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 13:36:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaw4-0003B1-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 10:55:21 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBYr4-0002yK-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 08:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYr3-0006GU-Q9; Thu, 08 Apr 2004 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYqn-00065c-8i for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 08:41: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 IAA11915 for ; Thu, 8 Apr 2004 08:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBYql-0002vw-00 for mmusic@ietf.org; Thu, 08 Apr 2004 08:41:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWTE-0002bZ-00 for mmusic@ietf.org; Thu, 08 Apr 2004 06:09:18 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BBUYE-000204-00 for mmusic@ietf.org; Thu, 08 Apr 2004 04:06:18 -0400 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3886JWR004529 for ; Thu, 8 Apr 2004 10:06:19 +0200 (MEST) Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 10:06:19 +0200 Received: from ericsson.com (research-ji5oqo.ki.sw.ericsson.se [147.214.34.102]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id H8FDBY7Y; Thu, 8 Apr 2004 10:07:12 +0200 Message-ID: <4072C5C6.5030107@ericsson.com> Date: Tue, 06 Apr 2004 16:59:18 +0200 X-Sybari-Trust: 44e4d1ed 2c4885b5 f5658c88 00000138 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: sv, en-us, en MIME-Version: 1.0 To: Andrew Large CC: geetha.srikantan@Sun.COM, mmusic@ietf.org Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming References: <001301c41815$a284f9a0$6001a8c0@alarge.net> In-Reply-To: <001301c41815$a284f9a0$6001a8c0@alarge.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 08:06:19.0076 (UTC) FILETIME=[5F832840:01C41D40] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Andrew Large wrote: > Please forgive me for jumping into the middle of this, but this area is > of considerable concern for us and I feel compelled to offer my $.02... > > First, Magnus, do I correctly capture your assertions? > > 1. The RTP-Info header need have only the "seq" or "rtptime" > clauses, but not both. > Yes, the header does not require both, however unless rtptime is used, synchronization is not achieved with this mechanism. > 2. For live streams, the server can provide "rtptime" values > that are meaningful to a client, even in the absence of a meaningful > Range header (e.g., when Range is "npt=now-"). Yes, however I have forgotten to point out that the case when using "npt=now-" will only achieve inter media synchronization when the media streams are under aggregated control. > > 3. The server should always have access to stream > synchronization information, so having the raw data necessary for > generating the "rtptime" values shouldn't be an issue. > Yes. > If I have correctly captured your position above, I have a few > questions/comments: > > a. [I apologize for not being on the list early enough to read > the entire dialog] Are you conceding the point that the server may not > know the sequence numbers of the first packets in each stream? Yes, and this is the case for the first PLAY for a live stream to server. And in this case the lack of sequence number will not effect the client. > > b. When one populates the "seq" clause, how "close" does it have > to be to the actual value? If it is acceptable to be off by some > amount, could you provide some concrete parameters? Either by time or > by sequence number value? (e.g., packet with given "seq" value must > have RTP timestamp within 500ms of that of the first packet actually > sent in that stream after the PLAY reply; or the first packet's sequence > number must differ by no more than N). > The point of sequence number in RTP-Info is to indicate the first RTP packet for which this synchronization information is valid. So it is not a matter of being able to be of with a certain amount. It is a matter of indicating from which packet the synch info is okay. So in a case where a server gives seq=C then the following observation can be done. When the client receives an RTP packet with sequence number X the following applies: if X=C: This packet uses the synch info. > c. When one populates the "Range" header with a real value, what > constraints are there (if any) on the relationship between that value > and the first packets actually sent in each stream? For example, > several servers simply report the value requested by the client and then > start their streams with packets whose timestamps fall <= the value in > the range header. In this case, the "rtptime" clause values in the > RTP-Info header (which must map to the Range header) will be >= the RTP > timestamps of the first packets actually received by the client. Note > that this behavior is preferable to support (among other things), very > long duration media samples. [If the reason for this is not clear, I'd > be happy to follow up with an example] > From draft version 6, chapter 11.4 PLAY "For a on-demand stream, the server MUST reply with the actual range that will be played back. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. If no range is specified in the request, the start position SHALL still be returned in the reply. If the medias that are part of an aggregate has different lengths, the PLAY request SHALL be performed as long as the given range is valid for any media, for example the longest media. Media will be sent whenever it is available for the given play-out point." So I think it is clear that one should report what time interval one is actually playing. However it is not likely that one will be able to for all media stream send out RTP packets which matches that time exactly. Therefore the capability you are indicating is required to be supported by a client. However it might be necessary to further clarify this. An example like the following may be worth adding. C->S: PLAY Range:npt=13.21-20 S->C 200 Ok Range:npt=13.160-20 RTP-Info: url=audio;seq=50;rtptime=50000,url=video;seq=12;rtptime=123400 Then the RTP media arrives: Audio (8kHz RTP timestamp rate): S -> C: RTP packet - seq = 50, rtptime = 49830, NPT time = 13.15125 s Video (90kHz RTP timestamp rate): S -> C: RTP packet - seq = 10, rtptime = 1234000, NPT time= 13.160 s So this indicate that it is expect that at least one media will have the same time as the indicate range in the response. However the client will need to handle that some media is prior than the requested and the indicated start time. What is currently not clear is if a server is allowed to send a audio packet with the following characteristics: Audio (8kHz RTP timestamp rate): S -> C: RTP packet - seq = 50, rtptime = 50100, NPT time = 13.1725 s In other words a packet that is later than the indicated play time but prior to the request time. Feedback on this is desired. > d. As a follow-up to [c], what constraints would there be on > the "implicit" value for the Range header in a live stream where it is > reported as "npt=now-", assuming that "rtptime" clauses are present in > the RTP-Info header. For example, could the server pick some point, > say, 5 minutes in the past as the synchronization point it will use to > generate the "rtptime" clause values? In theory it could, but it would be less nice behaviour, but a client could experience this and should be capable of handling, because it is almost equal to a session where one losses 5 minutes of data. If you have the time 5 minutes ago, you only need to perform a multiplication + an addition per media to give a time value for the current time. > > e. One of the most common current scenarios for distributing a > live broadcast is to have a "broadcaster" component that is *not* an > RTSP server -- it simply generates an RTP stream to a pre-defined set of > broadcast or unicast UDP ports and produces a ".sdp" file that describes > the broadcast. The SDP file is staged in the media root of a full > RTSP/RTP streaming server. When a client requests a session from the > ".sdp", the server parses the *.sdp (which it may only become aware of > at the point of the first client request) to figure out where it should > "listen" for the streams (there is no RTSP dialog between the server and > the broadcaster). In such a case, there is simply no way to guarantee > that the server knows *either* sequence number *or* synchronization > information for the streams before it needs to respond to the client. > In theory, this is disallowed by the new draft of the spec, is it not? > In practice, we (and others) have been using this method for years, and > it works just fine, so long as the client does not insist on having the > RTP-Info header. The client simply "resyncs" itself when the first SRs > actually arrive in the data stream. I realize that we're working on a > new mechanism (the relay work) that would have the broadcaster be an > RTSP client and thus pass along the synchronization information when it > "announces" the availability of the presentation, but do you really > think we should be breaking an existing facility at the same time as we > are introducing its replacement? Just to better understand the case: You are saying that the media root, is receiving the RTP stream from the broadcaster component, however it is totally ignoring it until a client requests it from the server? If the server was not ignoring the stream, and instead parsed the RTCP information it would have the information. Secondly, in the last revision we reduced the requirement on having RTP-Info from a MUST to a SHOULD, the current text says: 14.33 RTP-Info 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 SHOULD be part of a 200 response to PLAY. The exclusion of the RTP-Info in a PLAY response for RTP transported media will result in that a client needs to synchronize the media streams using RTCP. This may have negative impact as the RTCP can be lost, and does not need to be particulary timely in their arrival. Also functionality as informing the client from which packet a seek has occurred is affected. So the issue is simply if anyone is protesting against having this requirement on clients to handle media protocol (RTCP) for synch. > > f. Two editorial notes on the draft: > > + The separation of header syntax and sub-value > discussion (ala NPT discussion) from the header descriptions is very > confusing. It makes it quite difficult to get the full story on any one > attribute of the specification (you end up having to simply search for > keywords in the document, which is complicated in the case of RTP-Info > because it shows up in several examples). I think the main problem currently is that all headers description is lacking a bit of extra text to clarify syntax related questions. However I am not certain that I correctly understand you. Could you please better explain, and propose how to amend this problem. > > + Maybe I just don't know how to parse the syntax > properly, but it actually looks to me like the syntax asserts that the > "seq" and "rtptime" values are in fact mutually exclusive -- you can > only have one or the other (or is 1* supposed to be interpreted as "one > or more"?) 1* = one or more. 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 Thu Apr 8 13:37:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06879 for ; Thu, 8 Apr 2004 13:37:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdSI-0003z3-Nx for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 13:36:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38HakDa015309 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 13:36:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdSB-0003xS-0W for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 13:36:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06731 for ; Thu, 8 Apr 2004 13:36:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdS8-0004CR-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 13:36:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBaw2-0003Ap-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 10:55:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBYr4-0002yI-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 08:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYr3-0006GH-An; Thu, 08 Apr 2004 08:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBYqj-00064X-EW for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 08:41: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 IAA11910 for ; Thu, 8 Apr 2004 08:41:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBYqi-0002vf-00 for mmusic@ietf.org; Thu, 08 Apr 2004 08:41:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBWTD-0002bP-00 for mmusic@ietf.org; Thu, 08 Apr 2004 06:09:16 -0400 Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1BBUYD-000202-00 for mmusic@ietf.org; Thu, 08 Apr 2004 04:06:17 -0400 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3886HWR004515 for ; Thu, 8 Apr 2004 10:06:17 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 8 Apr 2004 10:06:17 +0200 Received: from ericsson.com (research-ji5oqo.ki.sw.ericsson.se [147.214.34.102]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 2P4H3F9J; Thu, 8 Apr 2004 10:06:50 +0200 Message-ID: <40725865.7020904@ericsson.com> Date: Tue, 06 Apr 2004 09:12:37 +0200 X-Sybari-Trust: 70920705 272a6e05 fe076738 00000139 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: sv, en-us, en MIME-Version: 1.0 To: Pekka Pessi CC: Jae-Hwan Kim , "mmusic (E-mail)" Subject: Re: [MMUSIC] ETag Definition in draft-rfc2326bis-06 References: <4060728A.2010606@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Apr 2004 08:06:17.0218 (UTC) FILETIME=[5E67A620:01C41D40] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks Pekka, See some comments below. Pekka Pessi wrote: > Magnus Westerlund writes: > >>Thanks for spotting this. I need some help with this as I have not a >>complete understanding of how ETag is supposed to work. I understand that >>they are server defined entities that only needs to follow the syntax. > > >>So what I understand there is need for a RTSP header "ETag:" that can >>be included in DESCRIBE and SETUP messages to be used to determine what >>content the client actually wants to SETUP or question if the description is >>up-to-date. > > > I *think* that the idea is when you get an SDP from HTTP server or > in response to DESCRIBE, you also get an a=etag. You then include > the tag in the If-Match header of the SETUP request. If the tag is > valid, the SETUP continues as usual. If the media resource has > changed (or the tag is not valid for any other reason) the server > should return 412. > > Now that ANNOUNCE/RECORD have been removed, I don't think we have > any use of If-Match with DESCRIBE. I agree that the usage of If-Match may not any longer be useful with DESCRIBE. However it is still useful for SETUP, where one can utilize in for example redirection to verify that one does SETUP on a resource where one has a valid session description. > > According to RFC 2326, 304 is returned when a DESCRIBE or > SETUP has an If-Modified-Since header. The Last-Modified/ > If-Modified-Since mechanism is borrowed from HTTP/1.0. The > description of 304 with ETag in bis-06, however, is pasted from > HTTP/1.1. > > So, when you get a 304 response with ETag in HTTP/1.1? Lets > suppose you have done GET and got 200 with the resource contents > and ETag: "xyzzy". Later you send GET with If-None-Match: "xyzzy", > if the server has not changed the resource it could respond with > 304 and the ETag "xyzzy". > > When using the HTTP/1.1 entity tags there can multiple versions > of the same resource, say, Swedish and Finnish web pages. The > server could select a particular version based on the request (in > this case, Accept-Language header in it). It would include a ETag > and Content-Location headers in the response (probably also the > Content-Language). A client (or proxy) could cache all the > different versions. It can ask server if one of them is valid for > a particular request by including all the cached ETags in the > If-None-Match header of the GET request. The 304 response would > then contain the ETag and Content-Location for the correct web > page. > > So, I think options for bis-07 are: > > 1) deprecate If-Modified-Since and introduce If-None-Match > 2) ditch ETag header in 304 and continue to use the current mix of > HTTP/1.0 and HTTP/1.1 mechanisms I don't think there are reasons to deprecated If-Modified-Since. It is still useful for cases when one likes to use HTTP dates. However adding If-None-Match to enabled conditional retrieves with DESCRIBE seems beneficial. > > >>Having a ETag header in the describe response seem to have some >>possibilities to clash with the SDP usage. In session >>descriptions it seems much better to have the ETag in the >>description so one does not have to add it if one for example >>saves the SDP. > > > Yes. However, I could imagine a "particular session description > language" that does not have etag, so the ETag header would be > needed. > Agree, then the proposal is to include also the ETag header in RTSP. Comments on this. Summary of proposed changes: - Add ETag header. - Add If-None-Match - Clarify If-Match - Clarify usage of ETags in general and their usage. Comments? Cheers Magnus -- 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 Apr 8 17:55:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29121 for ; Thu, 8 Apr 2004 17:55:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhUc-0003uk-Dd for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 17:55:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38LtQQv015046 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 17:55:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBhUb-0003uV-5q for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 17:55: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 RAA29079 for ; Thu, 8 Apr 2004 17:55:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBhUY-0001YO-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 17:55:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBfR4-0000m7-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 15:43:42 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBcOh-00059P-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 12:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBcOW-0002ww-0u; Thu, 08 Apr 2004 12:28:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBbqp-0000Rt-J7 for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 11:53: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 LAA00524 for ; Thu, 8 Apr 2004 11:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBbqo-000153-00 for mmusic@ietf.org; Thu, 08 Apr 2004 11:53:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBZnA-00014h-00 for mmusic@ietf.org; Thu, 08 Apr 2004 09:42:35 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by ietf-mx with esmtp (Exim 4.12) id 1BBX42-0000RU-00 for mmusic@ietf.org; Thu, 08 Apr 2004 06:47:18 -0400 Received: from esunmail ([129.147.156.34]) by brmea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i38AlKWo018117 for ; Thu, 8 Apr 2004 04:47:20 -0600 (MDT) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HVU00M4WLYVUA@edgemail1.Central.Sun.COM> for mmusic@ietf.org; Thu, 08 Apr 2004 04:47:19 -0600 (MDT) Received: from andrewlaptop ([209.128.69.139]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPSA id <0HVU00KBELYS3N@mail.sun.net> for mmusic@ietf.org; Thu, 08 Apr 2004 04:47:19 -0600 (MDT) Date: Thu, 08 Apr 2004 03:46:45 -0700 From: Andrew Large Subject: RE: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <4072C5C6.5030107@ericsson.com> To: "'Magnus Westerlund'" Cc: geetha.srikantan@Sun.COM, mmusic@ietf.org Message-id: <000e01c41d56$ca0b2ee0$6001a8c0@alarge.net> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT inline -- Andrew Large andrew.large@sun.com > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Tuesday, April 06, 2004 7:59 AM > To: Andrew Large > Cc: geetha.srikantan@sun.com; mmusic@ietf.org > Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming > > [snip] > > > If I have correctly captured your position above, I have a few > > questions/comments: > > > > a. [I apologize for not being on the list early enough to read > > the entire dialog] Are you conceding the point that the > server may not > > know the sequence numbers of the first packets in each stream? > > Yes, and this is the case for the first PLAY for a live stream to > server. And in this case the lack of sequence number will not > effect the > client. > Okay, fair enough. This can then probably be stated as "if you've got it, you should send it; if you don't, don't worry about it". One would assume that a stream that was paused and resumed would have sequence info. > > > > b. When one populates the "seq" clause, how "close" does it have > > to be to the actual value? If it is acceptable to be off by some > > amount, could you provide some concrete parameters? Either > by time or > > by sequence number value? (e.g., packet with given "seq" value must > > have RTP timestamp within 500ms of that of the first packet actually > > sent in that stream after the PLAY reply; or the first > packet's sequence > > number must differ by no more than N). > > > > The point of sequence number in RTP-Info is to indicate the first RTP > packet for which this synchronization information is valid. > So it is not > a matter of being able to be of with a certain amount. It is > a matter of > indicating from which packet the synch info is okay. So in a > case where > a server gives seq=C then the following observation can be done. > > When the client receives an RTP packet with sequence number X the > following applies: > > if X This packet does not use the synchronization received in the > RTP-Info + > Range. Synchronization must be based on previous synch info. It might > even be so that the most appropriate thing is to suppress this packet. > > If X>=C: > This packet uses the synch info. > So this sounds like "the seqno you send should be <= that of the first packet the client receives from you". So a client must be able to handle the case where the first packet has a seqno that is maybe 2 or 3 values greater than what was put in the RTP-Info header, right? If so, that solves one of my concerns about the race condition implicit in reflecting a live stream to several clients. > > > c. When one populates the "Range" header with a real value, what > > constraints are there (if any) on the relationship between > that value > > and the first packets actually sent in each stream? For example, > > several servers simply report the value requested by the > client and then > > start their streams with packets whose timestamps fall <= > the value in > > the range header. In this case, the "rtptime" clause values in the > > RTP-Info header (which must map to the Range header) will > be >= the RTP > > timestamps of the first packets actually received by the > client. Note > > that this behavior is preferable to support (among other > things), very > > long duration media samples. [If the reason for this is > not clear, I'd > > be happy to follow up with an example] > > > > From draft version 6, chapter 11.4 PLAY > > "For a on-demand stream, the server MUST reply with the > actual range > that will be played back. This may differ from the > requested range if > alignment of the requested range to valid frame boundaries is > required for the media source. If no range is specified in the > request, the start position SHALL still be returned in > the reply. If > the medias that are part of an aggregate has different > lengths, the > PLAY request SHALL be performed as long as the given > range is valid > for any media, for example the longest media. Media will be sent > whenever it is available for the given play-out point." > > So I think it is clear that one should report what time > interval one is > actually playing. However it is not likely that one will be > able to for > all media stream send out RTP packets which matches that time > exactly. > Therefore the capability you are indicating is required to be > supported > by a client. However it might be necessary to further clarify > this. An > example like the following may be worth adding. > > C->S: > PLAY > Range:npt=13.21-20 > > S->C > 200 Ok > Range:npt=13.160-20 > RTP-Info: > url=audio;seq=50;rtptime=50000,url=video;seq=12;rtptime=123400 > > Then the RTP media arrives: > > Audio (8kHz RTP timestamp rate): > S -> C: RTP packet - seq = 50, rtptime = 49830, NPT time = 13.15125 s > > Video (90kHz RTP timestamp rate): > S -> C: RTP packet - seq = 10, rtptime = 1234000, NPT time= 13.160 s > > > So this indicate that it is expect that at least one media > will have the > same time as the indicate range in the response. However the > client will > need to handle that some media is prior than the requested and the > indicated start time. What is currently not clear is if a server is > allowed to send a audio packet with the following characteristics: > > Audio (8kHz RTP timestamp rate): > S -> C: RTP packet - seq = 50, rtptime = 50100, NPT time = 13.1725 s > > In other words a packet that is later than the indicated play > time but > prior to the request time. > > Feedback on this is desired. > I guess that, if I had to, I could live with the constraint that (for "on demand" streaming) at least one 'rtptime' value must exactly equal the value of the first packet sent in one of the streams. I do feel quite strongly that this must be the "last" of the first packets (I think we're in agreement here). However, consider a hypothetical presentation that has a single MIDI stream. The MIDI stream has a duration of 30 seconds, broken into three samples (one packet per sample) with durations like this: packet 1: NPT=0.0 through 10.0 packet 2: NPT=10.0 through 20.0 packet 3: NPT=20.0 through 30.0 Now suppose that a user (via the client) requests a seek to NPT=7.0. By my original proposal, I'd set the Range header to "7.0", but send packet 1. The data sample within the packet would have its own internal timing information, which would let the client 'skip' the first 7 seconds of the MIDI sample and start playing at npt=7.0. With your constraint, I'd be forced to put either "0.0" or "10.0" in my Range header (depending upon which packet I selected). I submit that neither of these would be very palatable from an end-user perspective. Hopefully, its clear that I'm not arguing for an ability to start streams at an arbitrary point earlier than the "Range" response. Rather, I'm suggesting that the deviation from the Range header on *all* tracks could be as much as one media sample's duration. Just to be clear -- my example isn't all that contrived. We've definitely seen/streamed MIDI tracks, and there are efforts underway to develop "timed text" specifications which may very well have the same "long duration sample" properties. > > > d. As a follow-up to [c], what constraints would there be on > > the "implicit" value for the Range header in a live stream > where it is > > reported as "npt=now-", assuming that "rtptime" clauses are > present in > > the RTP-Info header. For example, could the server pick some point, > > say, 5 minutes in the past as the synchronization point it > will use to > > generate the "rtptime" clause values? > > In theory it could, but it would be less nice behaviour, but a client > could experience this and should be capable of handling, > because it is > almost equal to a session where one losses 5 minutes of data. If you > have the time 5 minutes ago, you only need to perform a > multiplication + > an addition per media to give a time value for the current time. > Right, so this was really a follow-up to the above discussion. I'm very much in favor of insisting (for "on demand" streams) that the value in the 'Range' header be >= the RTP timestamps of the first packets sent by the server in all streams. This gives a guarantee that a client has all the media necessary to begin the presentation at that NPT. However, in the case of a live stream, we aren't really saying anything in the Range header about where the 'presentation start' point is -- nor does a user/client select such a point. Everything is basically "now" (pause now, play now). Hence I find it difficult to justify any sort of required relationship between the 'RTP-Info' header 'rtptime' values and the first RTP timestamps the client receives (except the obvious that conversions from RTP timestamp to/from NPT must generate correct answers). This is one of my issues with requiring the RTP-Info header for live streams -- I don't like having two different modes of interpretation -- one for "on demand", and the other for "live". > > > > > e. One of the most common current scenarios for distributing a > > live broadcast is to have a "broadcaster" component that is *not* an > > RTSP server -- it simply generates an RTP stream to a > pre-defined set of > > broadcast or unicast UDP ports and produces a ".sdp" file > that describes > > the broadcast. The SDP file is staged in the media root of a full > > RTSP/RTP streaming server. When a client requests a > session from the > > ".sdp", the server parses the *.sdp (which it may only > become aware of > > at the point of the first client request) to figure out > where it should > > "listen" for the streams (there is no RTSP dialog between > the server and > > the broadcaster). In such a case, there is simply no way > to guarantee > > that the server knows *either* sequence number *or* synchronization > > information for the streams before it needs to respond to > the client. > > In theory, this is disallowed by the new draft of the spec, > is it not? > > In practice, we (and others) have been using this method > for years, and > > it works just fine, so long as the client does not insist > on having the > > RTP-Info header. The client simply "resyncs" itself when > the first SRs > > actually arrive in the data stream. I realize that we're > working on a > > new mechanism (the relay work) that would have the > broadcaster be an > > RTSP client and thus pass along the synchronization > information when it > > "announces" the availability of the presentation, but do you really > > think we should be breaking an existing facility at the > same time as we > > are introducing its replacement? > > Just to better understand the case: You are saying that the > media root, > is receiving the RTP stream from the broadcaster component, > however it > is totally ignoring it until a client requests it from the server? > > If the server was not ignoring the stream, and instead parsed > the RTCP > information it would have the information. > Almost, but not quite: * Broadcaster on host A is sending streams to host B, ports I and J. The individual who sets up the broadcast manually transfers a ".sdp" file into the content root on host B. * Server on host B has no idea that the broadcaster exists and has no idea that it has been given a new ".sdp" file. * Client requests the ".sdp" file * In servicing the request, server notes that it isn't currently receiving this broadcast and sets up listeners on ports I and J. This is the way most live streaming we have seen is actually done today. The notion that the server would hold up the PLAY reply until it receives RTCP SRs is problematic in a ton of ways. There is no guaranteed upper bound on this wait period. How long do you wait before you time out and reject the request? And what exactly are you gaining by waiting? You are making an end-user sit for (potentially) several seconds before media buffering even begins. How much do you lose by simply omitting the RTP-Info header and beginning immediate packet forwarding? Consider two cases: * SRs come very soon: user will have very short period of "slightly out of sync" presentation -- in fact, maybe none at all (because the client may be able to process the sync while still doing initial buffering). * SRs come after several secs: user will have long period of "out of sync" presentation before the receipt of the SRs syncs things up. However, if you force the wait, the user will simply spend those same seconds looking at a blank screen (and they'll never see that part of the presentation). > > Secondly, in the last revision we reduced the requirement on having > RTP-Info from a MUST to a SHOULD, the current text says: > > 14.33 RTP-Info > > 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 SHOULD be part of a 200 > response to PLAY. > > > The exclusion of the RTP-Info in a PLAY response for RTP > transported media will result in that a client needs to > synchronize the media streams using RTCP. This may have > negative impact as the RTCP can be lost, and does not need > to be particulary timely in their arrival. Also > functionality as informing the client from which packet a > seek has occurred is affected. > > > So the issue is simply if anyone is protesting against having this > requirement on clients to handle media protocol (RTCP) for synch. > > I guess my issue is that I think we need to bite the bullet and be clear that the requirements are simply different for live streams and "on demand" streams: * For reflected live streams, you may not be able to include SSRC in SETUP response (because you haven't seen any packets); for "on demand", you can. * For reflected live streams, the Range header is useless, except as a mechanism to signal that this *is* a live stream (e.g., npt=now-). For "on demand" streams, it is critical. * For reflected live streams, the RTP-Info header may simply not be there (and maybe even *shouldn't* be there); if it is there, it is interpreted a little differently than with "on demand" streams. For "on demand" streams, it should be there, fully populated, and deeply understood. > > > > f. Two editorial notes on the draft: > > > > + The separation of header syntax and sub-value > > discussion (ala NPT discussion) from the header descriptions is very > > confusing. It makes it quite difficult to get the full > story on any one > > attribute of the specification (you end up having to simply > search for > > keywords in the document, which is complicated in the case > of RTP-Info > > because it shows up in several examples). > > I think the main problem currently is that all headers description is > lacking a bit of extra text to clarify syntax related > questions. However > I am not certain that I correctly understand you. Could you please > better explain, and propose how to amend this problem. > Maybe an example would clarify this. I went to section 14.29 expecting to get the full definition of the Range header and how it is used. What I did *not* find in 14.29: * The different ways of specifying the range (had to go to sections 3.4, 3.5, and 3.6). * The "live streaming" correlation with "npt=now-" (section 11.4) * The actual syntax for the Range header (subtly buried in section 17.2.3) So what would be my proposal? Well, to define/describe things (like headers) in exactly one place in the spec and not split and distribute definitions, e.g.: * Put the syntax with the header description (e.g. ditch 17.2.3 and pull it into the header descriptions) * Pull in all the context-related usage that is scattered through other parts of the spec (suck 3.4, 3.5, 3.6 and relevant text in 11.4 into 14.29). Now, I realize this is probably more than you're willing to bite off at this point, but maybe there are some "low hanging fruit" things you might think of doing if you recognize and agree with the source of my frustration. BTW, a little better description of when you use what error codes would definitely be helpful. For example, what error should a server return if it attempts to parse a file requested for an "on demand" presentation and finds that the file is corrupted in some fashion? > > > > > + Maybe I just don't know how to parse the syntax > > properly, but it actually looks to me like the syntax > asserts that the > > "seq" and "rtptime" values are in fact mutually exclusive -- you can > > only have one or the other (or is 1* supposed to be > interpreted as "one > > or more"?) > > 1* = one or more. > Yeah, figured that one out after spending a little more time here :-) > > 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 Thu Apr 8 18:42:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03813 for ; Thu, 8 Apr 2004 18:42: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 1BBiDg-0007xd-Ly for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 18:42:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38Mg0JA030597 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 18:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBiDg-0007xL-Et for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 18:42: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 SAA03778 for ; Thu, 8 Apr 2004 18:41:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBiDc-0006zR-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 18:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgI9-0000UN-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 16:38:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBdWn-0004r6-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 13:41:25 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBdUa-0001xB-9T for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 13:39:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdUT-0004y3-I1; Thu, 08 Apr 2004 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBdTv-0004wV-PQ for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 13:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07083 for ; Thu, 8 Apr 2004 13:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBdTs-0004V0-00 for mmusic@ietf.org; Thu, 08 Apr 2004 13:38:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBazU-0003br-00 for mmusic@ietf.org; Thu, 08 Apr 2004 10:58:54 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BBYu9-0003Ve-00 for mmusic@ietf.org; Thu, 08 Apr 2004 08:45:13 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38Cj8819177; Thu, 8 Apr 2004 15:45:08 +0300 (EET DST) X-Scanned: Thu, 8 Apr 2004 15:44:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i38CieTq019323; Thu, 8 Apr 2004 15:44:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00JqA9gY; Thu, 08 Apr 2004 15:44:38 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i38CiVs07361; Thu, 8 Apr 2004 15:44:32 +0300 (EET DST) Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 8 Apr 2004 15:44:30 +0300 Received: from agni.research.nokia.com (hed040-205.research.nokia.com [172.21.40.205]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA27745; Thu, 8 Apr 2004 15:44:42 +0300 (EETDST) Received: from agni.research.nokia.com (localhost.localdomain [127.0.0.1]) by agni.research.nokia.com (8.12.8/8.12.8) with ESMTP id i38Chuc7004836; Thu, 8 Apr 2004 15:43:56 +0300 Received: (from ppessi@localhost) by agni.research.nokia.com (8.12.8/8.12.8/Submit) id i38Cht6p004835; Thu, 8 Apr 2004 15:43:55 +0300 X-Authentication-Warning: agni.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Magnus Westerlund Cc: Pekka Pessi , Jae-Hwan Kim , "mmusic (E-mail)" Subject: Re: [MMUSIC] ETag Definition in draft-rfc2326bis-06 X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <40725865.7020904@ericsson.com> (Magnus Westerlund's message of "Tue, 06 Apr 2004 09:12:37 +0200") References: <4060728A.2010606@ericsson.com> <40725865.7020904@ericsson.com> Date: Thu, 08 Apr 2004 15:43:54 +0300 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 08 Apr 2004 12:44:30.0741 (UTC) FILETIME=[3C851C50:01C41D67] Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Hello Magnus, Magnus Westerlund writes: >> So, I think options for bis-07 are: >> 1) deprecate If-Modified-Since and introduce If-None-Match >> 2) ditch ETag header in 304 and continue to use the current mix of >> HTTP/1.0 and HTTP/1.1 mechanisms >I don't think there are reasons to deprecated If-Modified-Since. >It is still useful for cases when one likes to use HTTP dates. >However adding If-None-Match to enabled conditional retrieves >with DESCRIBE seems beneficial. Yes, you are right. By "deprecating" I meant that no-one should build a new RTSP client that uses If-Modified-Since only. >Agree, then the proposal is to include also the ETag header in RTSP. >Comments on this. >Summary of proposed changes: >- Add ETag header. >- Add If-None-Match >- Clarify If-Match >- Clarify usage of ETags in general and their usage. >Comments? Also, a clarification of Accept-Language/Content-Language could be in order. Accept-Language now states that the language specified applies to the presentation description and any reason phrases, not the media content. However, ETag effectively allows clients and proxies to cache alternative contents for a particular resource. If we have two SDP descriptions for URI in different languages, I'd expect that they can refer to two different media resources. The actual media could be in different languages, too, but the language must be chosen before the SETUP is sent. For example, we can ask for Finnish SDP: C->S: DESCRIBE rtsp://localhost/news RTSP/1.0 Accept-Language: fi CSeq: 1 S->C: RTSP/1.0 200 OK CSeq: 1 Content-Location: /news.fi/sdp Content-Language: fi Content-Type: application/sdp Last-Modified: Wed, 07 Apr 2004 23:15:22 GMT Date: Thu, 08 Apr 2004 14:44:22 GMT ETag: "1d387f94c4bf2b8aad21271c27cd456e" Content-Length: ... v=0 o=news 32178463 8147637 IN IP6 ::1 s=Nyytiset t=0 0 a=range:npt=0-13:34 m=audio 8468 RTP/AVP 96 a=control:audio a=rtpmap:96 AMR-WB/16000 and swedish SDP: C->S: DESCRIBE rtsp://localhost/news RTSP/1.0 Accept-Language: se CSeq: 2 S->C: RTSP/1.0 200 OK CSeq: 2 Content-Location: /news.se/sdp Content-Language: se Content-Type: application/sdp Last-Modified: Thu, 08 Apr 2004 14:44:22 GMT ETag: "140940f8c9aa3e2a9df426cd1d626f7a" Content-Length: ... v=0 o=news 32178463 8147637 IN IP6 ::1 s=Uuheter t=0 0 a=range:npt=0-13:34 m=audio 8468 RTP/AVP 96 a=control:audio a=rtpmap:96 AMR-WB/16000 and then we can use the SDP (and Content-Location URL) to the select the language: C->S: SETUP rtsp//localhost/news.se/audio RTSP/1.0 CSeq: 3 Transport: RTP/AVP;unicast;client_port=5004-5005 S->C: RTSP/1.0 200 OK CSeq: 2 Session: 9bc0d7421edc303a93ae2dacc7117150 Transport: RTP/AVP;unicast;client_port=5004-5005;server_port=3056-3057 --Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 20:06:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13435 for ; Thu, 8 Apr 2004 20:06: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 1BBjWw-0000vR-OU for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 20:05:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3905wLq003553 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 20:05:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjWw-0000vA-Gs for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 20:05: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 UAA13330 for ; Thu, 8 Apr 2004 20:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjWu-0000nU-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 20:05:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBigs-0002HR-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 19:12:17 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBi9t-0006Z4-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 18:38:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBi9q-0007Vu-Pa; Thu, 08 Apr 2004 18: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 1BBi9X-0007Ma-UD for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 18: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 SAA03341 for ; Thu, 8 Apr 2004 18:37:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBi9U-0006Wo-00 for mmusic@ietf.org; Thu, 08 Apr 2004 18:37:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBgDL-0007UJ-00 for mmusic@ietf.org; Thu, 08 Apr 2004 16:33:39 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BBdR8-0003zD-00 for mmusic@ietf.org; Thu, 08 Apr 2004 13:35:35 -0400 Received: from alor ([130.209.247.84]:52790) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BBdQd-0004ru-00; Thu, 08 Apr 2004 18:35:03 +0100 Mime-Version: 1.0 (Apple Message framework v613) To: mmusic@ietf.org Message-Id: <2DD0D801-8983-11D8-8399-000A957FC5F2@csperkins.org> Content-Type: multipart/mixed; boundary=Apple-Mail-3-59335927 Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= From: Colin Perkins Date: Thu, 8 Apr 2004 18:35:50 +0100 X-Mailer: Apple Mail (2.613) Subject: [MMUSIC] Draft MMUSIC minutes Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 --Apple-Mail-3-59335927 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Folks, Draft minutes for the MMUSIC session at the 59th IETF in Seoul are attached. Please send any comments or corrections by Thursday 15th April, to meet the IETF publication deadline. Colin --Apple-Mail-3-59335927 Content-Type: text/plain; x-unix-mode=0660; name="minutes.txt" Content-Disposition: attachment; filename=minutes.txt Content-Transfer-Encoding: quoted-printable Minutes of the Multiparty Multimedia Session Control (MMUSIC) WG =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Reported by: J=F6rg Ott Notes by: Colin Perkins General ------- Colin Perkins, J=F6rg Ott The MMUSIC WG met once at the 59th IETF. The meeting was chaired by Colin Perkins and J=F6rg Ott. Some 100 people attended the meeting. J=F6rg reviewed the agenda, with no changes being requested. He also provided a brief status update: Several WG documents are with the IESG now, some of them waiting to be updated. No RFCs were published since the last IETF. Internet Media Guides --------------------- Rod Walsh, Juha-Pekka Luoma, Yuji Nomura - draft-ietf-mmusic-img-req-03.txt - draft-nomura-mmusic-img-framework-03.txt Rod Walsh discussed the changes since the last version in the two above WG documents. The requirements document has seen various clarifications and formal corrections. The problem statement was augmented to point to the holes existing IETF protocols leave in the problem space. The use cases were reordered, further cases covering subscribe/notify requirements were added. Delivery and description requirements were clarified. For the framework document, the descriptions of SUBSCRIBE and NOTIFY operations were improved, the draft was aligned with the requirements draft. Finally, again, formal and editorial corrections were made. Rod then presented the conceivable next steps: the documents are already in WGLC, so there are considered pretty much complete. Within the IMG framework, three potential new areas of work have been identified: an IMG transfer envelope, a multicast delivery protocol, and a subscribe notify mechanisms. Thoughts on all areas exist as individual drafts, and Rod requests they be added to the MMUSIC or appropriate other WG charter (see below). There is quite some interest from other bodies (including 3GPP and DVB) so this work should proceed. In the following, Pekka and Yuji outlined the suggested work items, starting from the framework draft and filling in the components needed: The transfer envelope is supposed to be an XML definition for a container that can carry arbitrary metadata as contents (draft-luoma-mmusic-img-metadata-envelope-00.txt). This could be done in MMUSIC. The multicast transport protocol should be designed as a specific instantiation of the FLUTE protocol spec from the RMT WG, as suggested in draft-luoma-mmusic-img-muppet-04.txt. This work could be in MMUSIC or in RMT. The unicast subscribe/notifiy mechanisms could be based upon the SIP event framework, but no draft exists here so far. This could be done in MMUSIC or SIPPING. The presentation provoked some discussion on whether it would be appropriate to think about using the SIP SUBSCRIBE/NOTIFY mechanism, as no obvious relation can be seen to other SIP work. It was noted that this work is less about personal presence than about conveying state changes in general, and it was requested that clear use cases and requirement be drawn up and sent to the SIPPING list for discussion. Furthermore, it was remarked that the XML encapsulation format will = become much easier if all data objects are labelled rather than allowing for generic XML to be encapsulated, e.g. for diffs. Yuji noted that a = generic encapsulation is necessary. There were no objections raised against continuing this work. Colin and J=F6rg were tasked to talk to the ADs and the chairs of the other = relevant working groups (particularly SIPPING and RMT) to determine where which = work should go and to initiate re-chartering MMUSIC accordingly. SDP Security Descriptions for Media Streams ------------------------------------------- Flemming Andreasen - draft-ietf-mmusic-sdescriptions-03.txt Flemming briefly reviewed the overall structure of the draft and the changes since the last revision: It consists of a core framework and parameter definitions, a specific instantiation of this framework for=20 SRTP, procedures on how to operate with, and without, offer/answer scheme, and a grammar. Quite a few changes have been made to the draft since -02: following consensus from the last IETF, support for multicast and multipoint SRTP sessions was removed, so was the SRC parameter. Rules for creating and removing crypto contexts are now more explicit. Numerous additions were made to clarify the use with offer/answer. Finally, the IANA registry structure was changed. Flemming pointed out one minor issue with offer/answer: with o/a, an initial crypto context is established. However, subsequent o/a exchanges may not just modify codec parameters but also peer addresses (IP address and/or port). In this case, the new entity may not have information about the current ROC value. The solution is to reset the ROC value to zero whenever any part of an address changes (at either end). A question was raised which changes would affect security; this seems to be restricted to the case of a transport address or port change at either end. The group felt the document was ready for WGLC. SDP Security Preconditions -------------------------- Flemming Andreasen - draft-andreasen-mmusic-securityprecondition-01.txt Flemming briefly introduced the problem to be addressed: during an offer/answer exchange, the offerer and answerer exchange security parameters. When the answered has picked a scheme (possibly one out of several offered) and the respective parameters, it can start sending media right away. The first packets of the secured media stream may reach the offerer before the answer, so that the offerer does not know which security description to use. RFC 3312 provides a solution by means of introducing preconditions which was suggested for this problem at the last IETF. In the meantime, no concerns were raised and no issues found so that this work is believed to be useful and also ready. It was tentatively agreed to adopt this as a WG item, pending charter discussion. SDP Connectivity Preconditions ------------------------------ Flemming Andreasen - draft-andreasen-mmusic-connectivityprecondition-00.txt Flemming introduced the problem to be addressed: various circumstances (e.g. deployment of NATs, firewalls, etc.) may interfere with packet transmission and may prevent media streams from flowing in either or both directions, even though call signaling setup succeeds. The = proposed approach is to re-use the precondition mechanism defined in RFC 3312 with a new precondition tag to indicate that a call shouldn't proceed until connectivity has been verified. To test whether media stream connectivity (which is only defined for RTP) is available, a mechanism such as STUN or the proposed new RTP NOOP payload format can be used (the draft doesn't mandate any particular connectivity check). Significant discussion arose concerning the relationship between this work and ICE (the latter being used to ensure that there is connectivity). Commenters found that the term "connectivity" needs a more precise definition in the draft to be able to take a binary decision of whether or not a connectivity precondition is satisfied. A further issue was raised in conjunction with SIP forking, as the initiator of a call may receive packets from multiple destinations and may be unable to tell which branch satisfied the precondition. Flemming believes the approach is workable and took up the task to explain this in more detail in a revised version. The chairs noted that there is clearly interest in the draft, but chartering this as an MMUSIC work item again requires a charter discussion first. Interactive Connectivity Establishment (ICE) -------------------------------------------- Jonathan Rosenberg - draft-ietf-mmusic-ice-01.txt Jonathan presented three issues and proposed solutions regarding the current ICE draft. Issue 1 is may occur with a port restricted flow if the called entity does not respond soon enough, e.g. with a 200 OK in the case of SIP (refer to the slides for details of the message flow). In this case, a STUN timeout may occur at the callee because the caller does not receive the 200 OK and start sending STUN packets itself (thereby creating the necessary binding in its local NAT) so that media connectivity is not established. This is a race condition between the STUN timeout and the answer from the callee. Jonathan has two solution proposals: solution 1 is to mandate an immediate answer, this can be achieved in SIP e.g. with a 183 conveying the necessary addressing information back to the caller, and to increase the STUN timeout. Solution 2 is to mandate a second ICE cycle to = re-check=20 STUN-allocated addresses; this solution increases the signaling overhead associated with session setup (not the setup delay!) but eliminates the race condition in all cases. Jonathan proposed solution 1 as the appropriate solution. A comment was made that a connectivity precondition may solve this issue which Jonathan argues against. A suggestion was made to avoid a second cycle with solution two, based upon the priority order of the connection type. Jonathan feels that basing this decision on the NAT type determination is too risky, since it is difficult to determine the type of NAT that is present. A question was raised whether or not this use of 183 would interfere with "early media" via 183; this will be checked. It was also proposed to extend the timeout until the "200 Ok" in solution 1, and there was some brief discussion of the implications of this..=20 No consensus was reached on issue 1. Jonathan will send mail to the list summarizing the issue and soliciting feedback. Issue 2 is on how to prioritize addressing information in ICE. So far, the intention is to minimize relaying and to prefer IPv6. There are, however, are other conceivable criteria, e.g. to maximize the number of hops across security networks, minimize path latency, minimize number of router hops, etc. The issue is (a) whether one of these criteria needs to be chosen and, if so, (b) which one. Jonathan argues that this is in essence a policy decision and ICE does not depend on any policy. It works as long as at least one uable address exists. Nevertheless, there may be many parties involved with different policies and preferences. With the work of SIP/SIPPING on session policies (e.g. allowing service providers to assert policies on media streams), the ICE address preference appears simply as another policy. Jonathan proposes to not fix address preferences but rather clarify, in the ICE spec, that there are different axes of optimizations and, document the existing algorithm. Other specs shall be allowed to define (informationally) other algorithms. A reference session policy should be described as a non-normative approach for finding out other policies. This proposal was found reasonable. Issue 3 addresses the interaction between ICE and RTP NOOP (a presentation on RTP NOOP was given). The NOOP format appears to have some commonalities with STUN: sent to RTP port, requests an immediate (RTCP) response, and checks for connectivity and QoS between endpoints. The same (except for QoS checks) can be said for STUN used by ICE. Jonathan briefly described the differences: NOOP uses RTP and hence is cleaner for RTP sessions; but ICE works for other protocols, too. NOOP uses RTCP for responses which are sent to different port and hence may not work through many NATs. ICE (STUN) also provides address allocation and uses username/password for validation while NOOP would require SRTP. The obvious options, given this commonality, are to either use only NOOP, to use only STUN, or to use both. There was a lot of discussion, trying to understand and clarify the differences between the drafts, with no clear conclusion. It is plain that clarification of use cases, and of the relationship and overlap between the various drafts, is needed. RTSP Update ----------- Magnus Westerlund - draft-ietf-mmusic-rfc2326bis-06.txt - draft-ietf-mmusic-rtsp-nat-02.txt - draft-zeng-mmusic-map-ice-rtsp-00.txt Magnus presented the current status of the RTSP core spec (see slides for the details). The spec has been progressing well. Out of the currently logged 40 bugs almost all are solved, with only six unresolved ones. The spec underwent major changes and restructuring: the use of RTP was rewritten, the syntax is now compiled in a single chapter, and a proposal on timing RTSP messages was included. The numerous minor updates are listed in the slides. Magnus discussed the open issues and their current status (elaborated on in detail on the slides). There was some discussion of options for authentication to prevent session hijacking, including the possibility to mandate use of RTSP over TLS, as an alternative to cryptographically random session IDs. It was also noted that we need to understand the use cases for destination redirection, to determine how big an open issue this is. Finally, Magnus presented those resolved issues that did not yet make it into the spec: RTSP proxies, use cases for RTSP, and the use of implicit redirects. Everyone is encouraged to review the revised spec in detail and comment! The editors will edit in the remaining issues. The teleconferences held for discussing and resolving issues shall be resumed. The goal is to finish the RTSP core spec in 2004. Next, Magnus reported on the interactions between RTSP and NATs. =20 As per the discussion during IETF-58, a requirement section was=20 added and the usage of ICE is now in a separate draft, and solution=20 proposals (regarding protocol changing mechanisms) were removed. The remaining open issues include to clarify the recommendations on working with ALGs, with specific recommendation to be provided for firewalls ALGs (which are different from NAT ALGs). An appropriate protocol modifying solution needs to be chosen. Various high-level proposals exist for the latter including using ICE (for a proposal exists which is briefly presented), embedding STUN in an RTSP server, and using symmetric RTP. Interested parties are requested to write drafts; these should be evaluated afterwards and a single solution should be selected. Temporal References within URIs ------------------------------- Conrad Parker - draft-pfeiffer-temporal-fragments-02.txt Conrad Parker motivated the work by the need to define links to time points and regions within a real-time media resource (e.g. a movie) so that pieces of interest can be referred to directly. The draft on rfc2396bis defines "?query" and "#fragment" to enable referring to a subpart of a resource. This is integrated with HTTP and other download in a straightforward fashion: the server interprets the URI with the additional parameters and returns only the selected piece of the resource.=20 Conrad notes that in RFC 2326 the handling of query identifiers and fragments is undefined. He suggests specific interpretations of queries and fragments for handlng by the server and the client, respectively. He raises various issues, particularly how the mechanism can be kept extensible. It was noted that, while there is a clear use case for fragment requests, it is less obvious why queries are useful. Some clarification was requested. Other short discussion suggests that -- rather than defining individual specific extensions for RTSP URIs and extending those every now and then -- it may be more appropriate if a generic header inclusion mechanism is defined, as for SIP. - * - --Apple-Mail-3-59335927-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 8 21:16:12 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19636 for ; Thu, 8 Apr 2004 21:16: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 1BBkcS-0003Fe-6M for mmusic-archive@odin.ietf.org; Thu, 08 Apr 2004 21:15:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i391FiNc012494 for mmusic-archive@odin.ietf.org; Thu, 8 Apr 2004 21:15:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBkcR-0003FP-8g for mmusic-web-archive@optimus.ietf.org; Thu, 08 Apr 2004 21:15: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 VAA19532 for ; Thu, 8 Apr 2004 21:15:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBkcO-0000m3-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 21:15:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBkKS-0006qE-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 20:57:10 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BBk76-0004JV-00 for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 20:43:21 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BBjuD-0005Jt-KL for mmusic-web-archive@ietf.org; Thu, 08 Apr 2004 20: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 1BBjtm-0005QP-F1; Thu, 08 Apr 2004 20:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBjmU-0002Fp-QM for mmusic@optimus.ietf.org; Thu, 08 Apr 2004 20:22: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 UAA14673 for ; Thu, 8 Apr 2004 20:21:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBjmO-0002KR-00 for mmusic@ietf.org; Thu, 08 Apr 2004 20:21:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBj44-0005NK-00 for mmusic@ietf.org; Thu, 08 Apr 2004 19:36:09 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BBhwk-0005DK-00 for mmusic@ietf.org; Thu, 08 Apr 2004 18:24:30 -0400 Received: from phys-mpk-2 ([129.146.11.82]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i38MNMc7000573 for ; Thu, 8 Apr 2004 16:23:23 -0600 (MDT) Received: from sun.com (jamba.SFBay.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 <0HVV0037SI8F5A@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Thu, 08 Apr 2004 15:24:16 -0700 (PDT) Date: Thu, 08 Apr 2004 15:25:01 -0700 From: Geetha Srikantan Subject: Re: [MMUSIC] draft-rfc2326-06 comments wrt live streaming In-reply-to: <40749E30.8050503@sun.com> Cc: Thomas Zeng , mmusic@ietf.org Reply-to: Geetha.Srikantan@Sun.COM Message-id: <4075D13D.7070200@sun.com> Organization: Sun Microsystems 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 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20031128 References: <72263E8E8622D611975C0002B32C19D805A180A1@misty.packetvideo.com> <40749E30.8050503@sun.com> 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Geetha Srikantan wrote: >> touched upon below). It is well known that RTP-Info is required to >> handle >> PLAY after PAUSE (see a discussion thread a few months ago in this >> mailing >> list). Fortunately I have not seen customers asking for PAUSE in live >> streaming. But others might have. I don't know. >> >> >> > [tz] Now a more interesting problem is for random positioning (as you > Live sessions can't be PAUSED, right? So this shouldn't be an issue.. > > geetha I meant to say - live streams can't be paused in the same sense as on-demand streams. PAUSE for on-demand streams, implies the capability to pick up from the PAUSE point. For live, resuming after a PAUSE will resume at the *current* position in the stream and not from the PAUSE point. geetha _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 9 09:36:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27153 for ; Fri, 9 Apr 2004 09: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 1BBwAo-0004lT-EY for mmusic-archive@odin.ietf.org; Fri, 09 Apr 2004 09:35:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39DZwmX018315 for mmusic-archive@odin.ietf.org; Fri, 9 Apr 2004 09:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBwAo-0004lK-A2 for mmusic-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 09:35: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 JAA27117 for ; Fri, 9 Apr 2004 09:35:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBwAm-0005tu-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 09:35:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBw96-0005gg-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 09:34:13 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BBw7y-0005X1-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 09:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBw7y-0004IW-Bl; Fri, 09 Apr 2004 09: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 1BBw7K-0004Ga-Fe for mmusic@optimus.ietf.org; Fri, 09 Apr 2004 09:32: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 JAA26976 for ; Fri, 9 Apr 2004 09:32:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBw7I-0005UD-00 for mmusic@ietf.org; Fri, 09 Apr 2004 09:32:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBw5G-0005FT-00 for mmusic@ietf.org; Fri, 09 Apr 2004 09:30:15 -0400 Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx with esmtp (Exim 4.12) id 1BBvzu-0004vR-00 for mmusic@ietf.org; Fri, 09 Apr 2004 09:24:42 -0400 Received: from paviliondeux ([194.206.151.59]) by smtp8.clb.oleane.net with ESMTP id i39DNtWH000918 for ; Fri, 9 Apr 2004 15:24:10 +0200 Message-Id: <200404091324.i39DNtWH000918@smtp8.clb.oleane.net> From: "peter" To: Date: Fri, 9 Apr 2004 15:24:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0097_01C41E46.B582AAC0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcQeNfG5m8RBg8h9TLmBHtk5rYXY0g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [MMUSIC] SSL VPN 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNSAFE,HTML_MESSAGE,MISSING_OUTLOOK_NAME autolearn=no version=2.60 This is a multi-part message in MIME format. ------=_NextPart_000_0097_01C41E46.B582AAC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . How to provide SSL-based remote access to a broad range of Web and legacy applications? . What about application performance and requirements? . Are encrypted application tunneling issues solved? . What differences with IPsec VPNs? These questions, among others, will be tackled by the most recognised experts in this field during the SSL VPN Conference to be held in Paris from November 30th to the 3rd of December, 2004. A call for proposals is online at: http://www.upperside.fr/sslvpn04/sslvpn04intro.htm ------=_NextPart_000_0097_01C41E46.B582AAC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

• = How to = provide SSL-based remote access to a broad range of Web and   legacy = applications?
• What about application performance and requirements?
• Are encrypted = application tunneling issues solved?
• What differences with = IPsec VPNs?

These questions, among others, will be tackled by the most recognised = experts in this field during the SSL VPN = Conference to be held in Paris from November 30th to the 3rd of December, = 2004.

 

A call for proposals is online = at:

http://www.upperside.fr/sslvpn04/sslvpn04intro.htm

 

------=_NextPart_000_0097_01C41E46.B582AAC0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 9 17:03:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21918 for ; Fri, 9 Apr 2004 17:03:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC390-0002Eu-8T for mmusic-archive@odin.ietf.org; Fri, 09 Apr 2004 17:02:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i39L2Y0r008608 for mmusic-archive@odin.ietf.org; Fri, 9 Apr 2004 17:02:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC390-0002El-3C for mmusic-web-archive@optimus.ietf.org; Fri, 09 Apr 2004 17:02:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21902 for ; Fri, 9 Apr 2004 17:02:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BC38v-0002fr-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 17:02:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BC2tV-0001Da-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 16:46:34 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BC2h5-0007Mo-00 for mmusic-web-archive@ietf.org; Fri, 09 Apr 2004 16:33:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC2gd-0003rW-RF; Fri, 09 Apr 2004 16:33:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BC1uw-00087f-F6 for mmusic@optimus.ietf.org; Fri, 09 Apr 2004 15:43:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15877; Fri, 9 Apr 2004 15:43:28 -0400 (EDT) Message-Id: <200404091943.PAA15877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 09 Apr 2004 15:43:28 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-11.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-11.txt Pages : 25 Date : 2004-4-9 This document defines general extensions for SDP and RTSP to carry messages, as specified by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, their use is meaningful only when complemented by an appropriate key management protocol. General guidelines are also given on how the framework should be used together with SIP and RTSP. The usage with the MIKEY key management protocol is also defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-11.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-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-9155853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-9155853.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Apr 10 07:48:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02854 for ; Sat, 10 Apr 2004 07:48:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCGy4-0003RB-Aj for mmusic-archive@odin.ietf.org; Sat, 10 Apr 2004 07:48:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ABmCfo013209 for mmusic-archive@odin.ietf.org; Sat, 10 Apr 2004 07:48:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCGy4-0003Qy-4Z for mmusic-web-archive@optimus.ietf.org; Sat, 10 Apr 2004 07:48: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 HAA02822 for ; Sat, 10 Apr 2004 07:48:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCGy2-0001fF-00 for mmusic-web-archive@ietf.org; Sat, 10 Apr 2004 07:48:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCGwm-0001NB-00 for mmusic-web-archive@ietf.org; Sat, 10 Apr 2004 07:46:53 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BCGv3-00014c-00 for mmusic-web-archive@ietf.org; Sat, 10 Apr 2004 07:45:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCGv0-00037O-BB; Sat, 10 Apr 2004 07:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BCGuH-00036p-Tk for mmusic@optimus.ietf.org; Sat, 10 Apr 2004 07:44: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 HAA02700 for ; Sat, 10 Apr 2004 07:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BCGuG-00012l-00 for mmusic@ietf.org; Sat, 10 Apr 2004 07:44:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BCGsl-0000kS-00 for mmusic@ietf.org; Sat, 10 Apr 2004 07:42:43 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BCGrl-0000YG-00 for mmusic@ietf.org; Sat, 10 Apr 2004 07:41:42 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61946 helo=[192.168.0.5]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BCGrE-0000um-00; Sat, 10 Apr 2004 12:41:08 +0100 Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <113DE2D6-8AE4-11D8-9065-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?J=F6rg_Ott?= From: Colin Perkins Date: Sat, 10 Apr 2004 12:41:55 +0100 To: mmusic@ietf.org X-Mailer: Apple Mail (2.613) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG last call: draft-ietf-mmusic-kmgmt-ext-11.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is to announce a working group last call on the key management extensions for SDP and RTSP (draft-ietf-mmusic-kmgmt-ext-11.txt). Please send any final comments on this draft to the mailing list by Friday 23rd April. If no substantive technical comments are received by that time, we will request the IESG consider this draft for publication as a Proposed Standard RFC. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Apr 13 17:29:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10092 for ; Tue, 13 Apr 2004 17:29: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 1BDVGz-0005hP-Iq for mmusic-archive@odin.ietf.org; Tue, 13 Apr 2004 17:16:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLGnjp021902 for mmusic-archive@odin.ietf.org; Tue, 13 Apr 2004 17:16:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDUxM-0002YJ-8q for mmusic-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 16:56: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 QAA07336 for ; Tue, 13 Apr 2004 16:56:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDUxJ-0001iy-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 16:56:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUqF-0000rV-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 16:49:12 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUiI-00004j-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 16:40:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTof-0004fX-DA; Tue, 13 Apr 2004 15:43:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTdt-0002rg-Og for mmusic@optimus.ietf.org; Tue, 13 Apr 2004 15:32:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01681; Tue, 13 Apr 2004 15:32:19 -0400 (EDT) Message-Id: <200404131932.PAA01681@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 13 Apr 2004 15:32:19 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 Framework for the Usage of Internet Media Guides Author(s) : R. Walsh, et al. Filename : draft-ietf-mmusic-img-framework-04.txt Pages : 23 Date : 2004-4-13 This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using SDP, SDPng or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, and the use of existing protocol to create an IMG delivery infrastructure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-framework-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-framework-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155301.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155301.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 Apr 13 17:35:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10562 for ; Tue, 13 Apr 2004 17:35:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDVJl-0007Uk-KH for mmusic-archive@odin.ietf.org; Tue, 13 Apr 2004 17:19:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DLJfxB028806 for mmusic-archive@odin.ietf.org; Tue, 13 Apr 2004 17:19:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDV2w-0004Zw-7M for mmusic-web-archive@optimus.ietf.org; Tue, 13 Apr 2004 17:02: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 RAA07857 for ; Tue, 13 Apr 2004 17:02:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDV2t-0002Me-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 17:02:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDUvS-0001Rx-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 16:54:36 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDUo2-0000gJ-00 for mmusic-web-archive@ietf.org; Tue, 13 Apr 2004 16:46:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDToi-0004fx-9H; Tue, 13 Apr 2004 15:43:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTe0-0002tZ-1k for mmusic@optimus.ietf.org; Tue, 13 Apr 2004 15:32:28 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01707; Tue, 13 Apr 2004 15:32:26 -0400 (EDT) Message-Id: <200404131932.PAA01707@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 13 Apr 2004 15:32:25 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-req-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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 : Protocol Requirements for Internet Media Guides Author(s) : Y. Nomura, et al. Filename : draft-ietf-mmusic-img-req-04.txt Pages : 21 Date : 2004-4-13 This memo specifies requirements for a protocol for accessing and updating Internet Media Guide (IMG) information for media-on-demand and multicast applications. These requirements are designed to guide development of an IMG protocol for efficient and scalable delivery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-req-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-req-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-13155313.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-req-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-13155313.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Apr 14 17:19:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27509 for ; Wed, 14 Apr 2004 17:19:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDres-0001T0-CY for mmusic-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELAwVJ005634 for mmusic-archive@odin.ietf.org; Wed, 14 Apr 2004 17:10:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrIl-0002SZ-2a for mmusic-web-archive@optimus.ietf.org; Wed, 14 Apr 2004 16:48: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 QAA24594 for ; Wed, 14 Apr 2004 16:48:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrIj-00029a-00 for mmusic-web-archive@ietf.org; Wed, 14 Apr 2004 16:48:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrH0-0001rj-00 for mmusic-web-archive@ietf.org; Wed, 14 Apr 2004 16:46:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BDrEb-0001Qe-00 for mmusic-web-archive@ietf.org; Wed, 14 Apr 2004 16:43:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDqGI-0003O9-Hx; Wed, 14 Apr 2004 15:41:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDq9E-0003zh-Cx for mmusic@optimus.ietf.org; Wed, 14 Apr 2004 15:34:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18406; Wed, 14 Apr 2004 15:34:09 -0400 (EDT) Message-Id: <200404141934.PAA18406@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 14 Apr 2004 15:34:09 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-06.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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-06.txt Pages : 21 Date : 2004-4-14 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-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-bwparam-06.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-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-4-14153543.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-bwparam-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-bwparam-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-14153543.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Apr 28 14:18:09 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05370 for ; Wed, 28 Apr 2004 14:18:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItVv-0000Cb-Rk for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 14:10:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SIAVMZ000777 for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 14:10:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItPH-0006PM-F0 for mmusic-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 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 OAA04370 for ; Wed, 28 Apr 2004 14:03:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BItPD-0003rc-R7 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 14:03:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BItON-0003na-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 14:02:44 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BItNr-0003j3-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 14:02:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BItAB-0003b8-3U; Wed, 28 Apr 2004 13:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIt5m-0002aT-K7 for mmusic@optimus.ietf.org; Wed, 28 Apr 2004 13:43: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 NAA02537 for ; Wed, 28 Apr 2004 13:43:28 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIt5j-0002Sv-1t for mmusic@ietf.org; Wed, 28 Apr 2004 13:43:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIt4t-0002PN-00 for mmusic@ietf.org; Wed, 28 Apr 2004 13:42:36 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIt47-0002Kn-00; Wed, 28 Apr 2004 13:41:47 -0400 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHflG29089; Wed, 28 Apr 2004 20:41:47 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 20:41:38 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i3SHfcaK010895; Wed, 28 Apr 2004 20:41:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00CeIlaL; Wed, 28 Apr 2004 20:41:37 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SHfaH11037; Wed, 28 Apr 2004 20:41:36 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 20:41:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 20:41:34 +0300 Message-ID: Thread-Topic: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-bwparam-06.txt Thread-Index: AcQiYWWlGJ3m4fX3Rbazk0G2F+ejsQK4ukEQ To: , X-OriginalArrivalTime: 28 Apr 2004 17:41:36.0200 (UTC) FILETIME=[0D954C80:01C42D48] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Session Description for FLUTE Sessions (aka FLUTE 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,NO_EXPERIENCE,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello World I would like to ask for ideas and opinions on a session description for = FLUTE sessions. (FLUTE is the unidirectional file delivery protocol from = the Reliable Multicast Transport WG - draft-ietf-rmt-flute-07.txt - like = an RTP for files at a small stretch of the imagination). In short, to use FLUTE certain out-of-band information is mandatory and = optional. Although this can be sought by any number of proprietary and = closed methods, it's likely to be a big help to have an open document on = how to describe this in a way also suitable for the general Internet. = Thus, I want to build up some initial expert (and novice) opinions on = the semantics and syntax of what would be needed. FLUTE and ALC provide a starter-kit of data items which can easily be = turned into a semantic description. For syntax, it seems SDP is the = natural choice and SDP already comes with a decent tool kit of = attributes to reuse. (This is not to say SDPng and others would be = inappropriate, just that to start the work now SDP seems to be the only = show in town). Some other relevant context is that 3GPP (MBMS/SA4) has identified the = need for such a FLUTE session description, and the time constraints of = 3GPP release 6 (September freeze) offer a minimal window to do a 2 way = swap of ideas and agreement before a standard is needed. I certainly = have no experience in turning out RFC's in 5 months flat (anyone? :), = but a serious attempt to work on the issue in the next few months would = be an excellent way of ensuring a single interoperable method (and open = standard). In addition, I am expecting ETSI/DVB to make a "call for = technologies" in this area within a few weeks so the benefits of rapid = progress should be pretty obvious (but don't shoot me for suggesting it = :) Who wants to get involved? Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Apr 28 17:59:51 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26781 for ; Wed, 28 Apr 2004 17:59:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwuo-0005cx-LE for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLmQNc021627 for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIweZ-0005hA-KL for mmusic-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:31: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 RAA24319 for ; Wed, 28 Apr 2004 17:31:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIweW-00018B-2X for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:31:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwcY-0000mv-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:29:35 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIwaK-0000Mf-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:27:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwKl-00026o-2o; Wed, 28 Apr 2004 17:11:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIv6X-0006mQ-FL for mmusic@optimus.ietf.org; Wed, 28 Apr 2004 15:52: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 PAA12611 for ; Wed, 28 Apr 2004 15:52:23 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIv6U-0002yD-L5 for mmusic@ietf.org; Wed, 28 Apr 2004 15:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIv5Y-0002uH-00 for mmusic@ietf.org; Wed, 28 Apr 2004 15:51:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BIv4a-0002ra-00 for mmusic@ietf.org; Wed, 28 Apr 2004 15:50:24 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJoNv07049 for ; Wed, 28 Apr 2004 22:50:23 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 22:50:14 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3SJoEFO001880 for ; Wed, 28 Apr 2004 22:50:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00GAQHeD; Wed, 28 Apr 2004 22:50:12 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJoBH24072 for ; Wed, 28 Apr 2004 22:50:11 +0300 (EET DST) Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 22:50:00 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 22:50:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 22:49:59 +0300 Message-ID: Thread-Topic: [MMUSIC] Re: draft-rajeshkumar-mmusic-gpmd-03.txt Thread-Index: AcPaUJ5IFG1lwVwVRDaro/YtZ/wEgxTBqiCg To: X-OriginalArrivalTime: 28 Apr 2004 19:50:01.0948 (UTC) FILETIME=[FE9121C0:01C42D59] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] SDP and SDP-new: control media type Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable (if you're not an SDP guru, you may wish to check the relevant snips at = the bottom first) For sdp-new... Since conference is a subset (example) of session, is there any good = reason why the control media type is for "conference control channel for = the session" as opposed to "any control channel for the session"? My reason for asking is: if a media were entirely dedicated to control = data, but the session were not a conference (e.g. a webcast) then the = natural media type would still seem to be control even though the SDP = spec seems to disallow this (in favour of data media type) - which seems = odd. If there are no great reasons for the limitation to conferece control, = why not change the sdp text to say: "control" is used to specify an additional control channel for the = session. Cheers, Rod. Note, relevant snips are: sdp-new (and SDP) describe the "control" media type usage as: The first sub-field is the media type. Currently defined media are "audio", "video", "application", "data" and "control" ... ... "control" is used to specify an additional conference control channel for the session. (e.g. m=3Dcontrol 49234 H323 mc) And also defines session and conference thus: Conference: A multimedia conference is a set of two or more communicating users along with the software they are using to communicate. Session: A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Apr 28 17:59:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26834 for ; Wed, 28 Apr 2004 17:59:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwuw-0005j8-O6 for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3SLmYUW022009 for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 17:48:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwgN-00068M-Ts for mmusic-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 17:33: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 RAA24599 for ; Wed, 28 Apr 2004 17:33:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIwgK-0001Pt-8A for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:33:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIwfN-0001Hu-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:32:30 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BIwdu-000112-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 17:30:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIwMD-0002mP-LF; Wed, 28 Apr 2004 17:12:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BIvEQ-0001K5-5i for mmusic@optimus.ietf.org; Wed, 28 Apr 2004 16:00:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13407 for ; Wed, 28 Apr 2004 16:00:32 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BIvEN-0003vQ-B7 for mmusic@ietf.org; Wed, 28 Apr 2004 16:00:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BIvDO-0003o4-00 for mmusic@ietf.org; Wed, 28 Apr 2004 15:59:30 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BIvCV-0003jt-00 for mmusic@ietf.org; Wed, 28 Apr 2004 15:58:35 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJwaG00973 for ; Wed, 28 Apr 2004 22:58:36 +0300 (EET DST) X-Scanned: Wed, 28 Apr 2004 22:58:29 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3SJwTBF013225 for ; Wed, 28 Apr 2004 22:58:29 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 006UT8oi; Wed, 28 Apr 2004 22:58:27 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3SJwRH04683 for ; Wed, 28 Apr 2004 22:58:27 +0300 (EET DST) Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 22:58:27 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 28 Apr 2004 22:58:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Apr 2004 22:58:25 +0300 Message-ID: Thread-Topic: [MMUSIC] Re: draft-rajeshkumar-mmusic-gpmd-03.txt Thread-Index: AcPaUJ5IFG1lwVwVRDaro/YtZ/wEgxTBqiCgAAC0LRA= To: X-OriginalArrivalTime: 28 Apr 2004 19:58:28.0063 (UTC) FILETIME=[2C3C26F0:01C42D5B] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] And one more SDP-quiz question on protocol IDs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable One of the implications of wanting an SDP description for FLUTE = (previous email) is that we will need a protocol ID for the m line. = Although this seems trivial to me, I would like to know if anyone has = any great objections to "UDP/FLUTE" style? ("RTP/AVT", "udp" and "TCP" = are existing examples) So for example, you'd get an media field looking like this: m=3Ddata 12345 UDP/FLUTE 0=20 (Any reason not to prefer "FLUTE/UDP"?) Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Apr 28 23:56:47 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15620 for ; Wed, 28 Apr 2004 23:56:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2a6-0007RW-8x for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 23:51:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T3pQxv028600 for mmusic-archive@odin.ietf.org; Wed, 28 Apr 2004 23:51:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2N2-0004Mf-3e for mmusic-web-archive@optimus.ietf.org; Wed, 28 Apr 2004 23:37: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 XAA14360 for ; Wed, 28 Apr 2004 23:37:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ2Mw-0004Lx-W0 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 23:37:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ2Lw-0004FX-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 23:36:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ2Lj-00049T-00 for mmusic-web-archive@ietf.org; Wed, 28 Apr 2004 23:36:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ2HK-00036a-3d; Wed, 28 Apr 2004 23:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ29P-0001UF-Sk for mmusic@optimus.ietf.org; Wed, 28 Apr 2004 23: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 XAA13647 for ; Wed, 28 Apr 2004 23:23:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ29K-0002pS-QK for mmusic@ietf.org; Wed, 28 Apr 2004 23:23:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ28R-0002iw-00 for mmusic@ietf.org; Wed, 28 Apr 2004 23:22:52 -0400 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1BJ27W-0002aY-00 for mmusic@ietf.org; Wed, 28 Apr 2004 23:21:55 -0400 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 28 Apr 2004 20:21:06 -0700 Delivered-To: robla@real.com >Return-Path: Received: from sc8-sf-list1.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by scarface.real.com with esmtp; Wed, 28 Apr 2004 20:19:13 -0700 Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1BJ250-0006ZB-4l for robla@real.com; Wed, 28 Apr 2004 20:19:18 -0700 Date: Wed, 28 Apr 2004 20:06:41 -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: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #123 - 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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-944002 ] Clarify port number usage (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 28 Apr 2004 14:06:00 -0700 Subject: [rtspspec-bugs] [ rtspspec-Bugs-944002 ] Clarify port number usage Bugs item #944002, was opened at 2004-04-28 14:05 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=944002&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify port number usage Initial Comment: In version 06 of the draft, there is some new text that says that "RTCP/UDP packets from the client to the server SHALL be sent to ... first odd port number ... in client_port range". This sounds backwards to me. I think that if the client wants to send RTCP packets to the server, they should be sent to the "server_port" RTCP port, not the "client_port" RTCP port. Surely there is no guarantee that the server would be listening for incoming packets on the "client_port" ports? The next paragraph says, "The client SHOULD send its RTCP/UDP packets from the ... first odd port number specified in "server_port" parameter." Shouldn't that be "client_port"? The client may be unable to bind to the "server_port" ports. There are similar problems a couple of paragraphs further down, in the section that talks about the new "src_addr" and "dest_addr" parameters. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=944002&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 Apr 29 04:09:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12552 for ; Thu, 29 Apr 2004 04:09:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6Vm-0003h0-Ed for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 04:03:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3T83EKE014189 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 04:03:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ6R0-0002j4-JP for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 03:58: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 DAA11900 for ; Thu, 29 Apr 2004 03:58:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ6Qt-0001cr-3q for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 03:58:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ6Q4-0001Pp-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 03:57:21 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BJ6P8-0001Dq-04 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 03:56:23 -0400 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1BJ6Ii-0000ZR-CT for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 03:49:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ69K-0007fU-Cd; Thu, 29 Apr 2004 03:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ64Q-00063A-N1 for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 03:34: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 DAA10729 for ; Thu, 29 Apr 2004 03:34:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ64J-0005oR-CF for mmusic@ietf.org; Thu, 29 Apr 2004 03:34:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ63O-0005fv-00 for mmusic@ietf.org; Thu, 29 Apr 2004 03:33:55 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BJ62j-0005Xm-00 for mmusic@ietf.org; Thu, 29 Apr 2004 03:33:14 -0400 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3T7XFAh006887 for ; Thu, 29 Apr 2004 09:33:15 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 09:33:16 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.138]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J5LLKKGL; Thu, 29 Apr 2004 09:33:21 +0200 Message-ID: <4090AFBB.7020809@ericsson.com> Date: Thu, 29 Apr 2004 09:33:15 +0200 X-Sybari-Trust: e7bbfb97 f0b06ce5 3b9bea38 00000139 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: sv, en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2004 07:33:16.0614 (UTC) FILETIME=[3C8C3660:01C42DBC] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rod, A few comments, first it is RTP/AVP or RTP/SAVP, and in the near future also RTP/AVPF and RTP/SAVPF. I assume it was only a typo. Personally I prefer FLUTE/UDP, which seems to be the more clear that the main protocol information is FLUTE, which in this case is transported over UDP. If anyone has another transport FOO that will work for FLUTE then they can specify FLUTE/FOO. I don't think that using "data" as media type is appropriate at all. Although RFC 2327 mentions data I don't think it is appropriate at the current state. The media types that really is used to my knowledge is the ones using the names registered for MIME. See: http://www.iana.org/assignments/media-types/index.html If one looks at draft-ietf-mmusic-sdp-new-15.txt the following paragraph is present: "9.2.1 Media types ("media") The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level MIME content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing MIME top-level content types, 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 [5]." In this respect I think that "application" is suitable for FLUTE. Can you please further motivate why data would be the right choice? To avoid further confusion I am of the opinion that draft-ietf-sdp-new should be updated to move all unregistered media types into a note like: Note: RFC 2326 mentions the media types "data" and "control", these are unregistered media types and should not be used. If these media types are deemed suitable in the future, they should be registered in accordance with section 9.2.1. Cheers Magnus Rod.Walsh@nokia.com wrote: > One of the implications of wanting an SDP description for FLUTE (previous email) is that we will need a protocol ID for the m line. Although this seems trivial to me, I would like to know if anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT", "udp" and "TCP" are existing examples) > > So for example, you'd get an media field looking like this: > m=data 12345 UDP/FLUTE 0 > > (Any reason not to prefer "FLUTE/UDP"?) > > Cheers, Rod. > > _______________________________________________ > 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 Thu Apr 29 07:47:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21613 for ; Thu, 29 Apr 2004 07:47:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9yR-0002fw-Cd for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 07:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TBj3ih010284 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 07:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9qy-0000p3-FU for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 07:37: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 HAA21139 for ; Thu, 29 Apr 2004 07:37:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9qo-0001VV-TF for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:37:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9q1-0001Id-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:36:22 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ9pG-000166-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:35:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9f4-0006tS-3q; Thu, 29 Apr 2004 07:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9Yd-0005k3-Co for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 07:18:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20528 for ; Thu, 29 Apr 2004 07:18:16 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9YU-0005iK-2U for mmusic@ietf.org; Thu, 29 Apr 2004 07:18:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9XW-0005WN-00 for mmusic@ietf.org; Thu, 29 Apr 2004 07:17:15 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJ9Ws-0005KV-00 for mmusic@ietf.org; Thu, 29 Apr 2004 07:16:34 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TBGYv28223; Thu, 29 Apr 2004 14:16:34 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 14:15:39 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3TBFdE2005660; Thu, 29 Apr 2004 14:15:39 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00uVcsCh; Thu, 29 Apr 2004 14:15:38 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TBFVH06092; Thu, 29 Apr 2004 14:15:31 +0300 (EET DST) Received: from esebe021.NOE.Nokia.com ([172.21.138.104]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 14:15:31 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe021.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 14:15:32 +0300 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] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 14:15:30 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQtvI3qO25XPhzOT1ezTNgJsc42+gAHnwDw To: Cc: X-OriginalArrivalTime: 29 Apr 2004 11:15:32.0043 (UTC) FILETIME=[491531B0:01C42DDB] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable ...and... I prefer FLUTE/UDP as to protocol ID too, but am keeping an open mind = for now. Cheers, Rod. > -----Original Message----- > From: ext Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: Thursday, April 29, 2004 10:33 AM > To: Walsh Rod (Nokia-NRC/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs >=20 >=20 > Hi Rod, >=20 > A few comments, >=20 > first it is RTP/AVP or RTP/SAVP, and in the near future also RTP/AVPF=20 > and RTP/SAVPF. I assume it was only a typo. >=20 > Personally I prefer FLUTE/UDP, which seems to be the more=20 > clear that the=20 > main protocol information is FLUTE, which in this case is transported=20 > over UDP. If anyone has another transport FOO that will work=20 > for FLUTE=20 > then they can specify FLUTE/FOO. >=20 > I don't think that using "data" as media type is appropriate at all.=20 > Although RFC 2327 mentions data I don't think it is=20 > appropriate at the=20 > current state. The media types that really is used to my knowledge is=20 > the ones using the names registered for MIME. See: > http://www.iana.org/assignments/media-types/index.html >=20 > If one looks at draft-ietf-mmusic-sdp-new-15.txt the=20 > following paragraph=20 > is present: >=20 > "9.2.1 Media types ("media") >=20 > The set of media types is intended to be small and SHOULD NOT be > extended except under rare circumstances. The same rules should > apply for media names as for top-level MIME content=20 > types, and where > possible the same name should be registered for SDP as=20 > for MIME. For > media other than existing MIME top-level content types, a > standards-track RFC MUST be produced for a new top-level=20 > 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 [5]." >=20 > In this respect I think that "application" is suitable for FLUTE. Can=20 > you please further motivate why data would be the right choice? >=20 > To avoid further confusion I am of the opinion that=20 > draft-ietf-sdp-new=20 > should be updated to move all unregistered media types into a=20 > note like: >=20 > Note: RFC 2326 mentions the media types "data" and "control",=20 > these are=20 > unregistered media types and should not be used. If these media types=20 > are deemed suitable in the future, they should be registered in=20 > accordance with section 9.2.1. >=20 > Cheers >=20 > Magnus >=20 >=20 > Rod.Walsh@nokia.com wrote: >=20 > > One of the implications of wanting an SDP description for=20 > FLUTE (previous email) is that we will need a protocol ID for=20 > the m line. Although this seems trivial to me, I would like=20 > to know if anyone has any great objections to "UDP/FLUTE"=20 > style? ("RTP/AVT", "udp" and "TCP" are existing examples) > >=20 > > So for example, you'd get an media field looking like this: > > m=3Ddata 12345 UDP/FLUTE 0=20 > >=20 > > (Any reason not to prefer "FLUTE/UDP"?) > >=20 > > Cheers, Rod. > >=20 > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > >=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 From exim@www1.ietf.org Thu Apr 29 07:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21864 for ; Thu, 29 Apr 2004 07:54: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 1BJA1m-0003M3-TW for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 07:48:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TBmUxD012890 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 07:48:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9ya-0002in-QJ for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 07:45: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 HAA21539 for ; Thu, 29 Apr 2004 07:45:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9yR-0003Af-7W for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:45:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9xT-0002xu-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:44:04 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJ9wS-0002kU-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 07:43:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9qh-0000nv-D0; Thu, 29 Apr 2004 07:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJ9gK-00074j-1Y for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 07:26: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 HAA20761 for ; Thu, 29 Apr 2004 07:26:13 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJ9gA-0007DS-H8 for mmusic@ietf.org; Thu, 29 Apr 2004 07:26:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJ9fK-00071d-00 for mmusic@ietf.org; Thu, 29 Apr 2004 07:25:19 -0400 Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx with esmtp (Exim 4.12) id 1BJ9ej-0006p4-00 for mmusic@ietf.org; Thu, 29 Apr 2004 07:24:41 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TBOhG12481; Thu, 29 Apr 2004 14:24:43 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 14:24:09 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i3TBO9Wm031919; Thu, 29 Apr 2004 14:24:09 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 004gWxCK; Thu, 29 Apr 2004 14:24:05 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TBDjH04559; Thu, 29 Apr 2004 14:13:45 +0300 (EET DST) Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 14:13:36 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 14:13:36 +0300 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] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 14:13:35 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQtvI3qO25XPhzOT1ezTNgJsc42+gAFWC1w To: Cc: X-OriginalArrivalTime: 29 Apr 2004 11:13:36.0704 (UTC) FILETIME=[0455DC00:01C42DDB] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks Magnus One thing to make clear on the media type with FLUTE: I'm happy with = anything that's simple and works. (I just want to check that the = reasoning behind whatever media types are allowed for FLUTE usage are = solid enough so we don't need to rake over the question many times.) I Agree that "application" is the natural fit for "FLUTE applications". = We do need to answer 2 questions though: 1. do we need to specify which media types are allowed? (if not, then we = allow all) 2. do we need to exclude certain ones? (like the unregistered ones, and = how does this impact the SDP spec?) --- --- --- --- A quick trawl through RFC2045 found me: type :=3D discrete-type / composite-type discrete-type :=3D "text" / "image" / "audio" / "video" / "application" / extension-token composite-type :=3D "message" / "multipart" / extension-token extension-token :=3D ietf-token / x-token ietf-token :=3D x-token :=3D RFC2046 kindly explains these media types: "text", "image", "audio", = "video", "application", "multipart" and "message". I'm coming to the opinion that we can allow any of the media types in a = FLUTE "m line". Naturally any impementation would have to adhere to the = media type definitions: a FLUTE channel (given by an m line) would only = deliver files of the described media type (to ensure no impact on = multi-channel congestion control schemes, I supect this is practically = the same as saying the media type will be the same for the whole = session). So this would mean: * you may use the application type for any file typess delivered and = rendered to the user by the FLUTE receiver * you may use the audio type if only audio files are delivered and = rendered to the user by the FLUTE receiver * you may use the video type if only video files are delivered and = rendered to the user by the FLUTE receiver etc... So, for all but the most specialised FLUTE implementations, we'd expect = the "application" media type. This may be as much as needs to be said in = a "SDP for FLUTE" I-D. --- this draws a line under my comments on "one or many media types = allowed" --- The issue about allowing the use of "data" and "control" is that SDP = defines them so their use would be expected, but IANA has not registered = them. Any idea why on earth these are not registered? Since SDP makes it = clear that it's minimal set is to be rarely extended, surely the use of = data and control is totally fine with SDP, regardless of the IANA = registration? The issue about allowing the use of "message" and "multipart" is that = SDP does not define them but IANA has them registered. sdp-new text = makes it clear that no further RFC is needed for these existing MIME top = level types to be used - but what is actually needed (anything?) is = unclear. (This is more academic interest than me having a real need). --- now on when "data" might be prefered over "applciation" --- SDP gave me the impression that "application" is suitable where 'the = receiver renders the content to the user directly' and "data" is = suitable where 'the receiver does not directly render the content to the = user' (e.g. where the FLUTE receiver and media player are seperate = applications): ...The difference between "application" and "data" is that the former is a media flow such as whiteboard information, and the latter is bulk-data transfer such as multicasting of program executables which will not typically be displayed to the user.=20 So the example of "m=3Ddata..." was based on trying to do what the spec = asks for (not on any strong preference) and was not intended to exculude = "m=3Dapplication...". --- --- --- --- Since the quantity of text may have made this unclear, here's the bottom = line: * Practically anything if fine for me, including "application" only * I want strong arguments for the way we go so that we don't need to = re-enter this issue Cheers, Rod. PS Yep, AVT was a typo for AVP - oops _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 09:03:48 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28027 for ; Thu, 29 Apr 2004 09:03:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAio-0004t8-Bt for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 08:32:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TCWwm7018788 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 08:32:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAeh-0003gG-1X for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 08:28: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 IAA24497 for ; Thu, 29 Apr 2004 08:28:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAeX-00051W-1l for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 08:28:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAcq-0004Sc-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 08:26:49 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJAb5-0003uB-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 08:24:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJASP-00015w-U8; Thu, 29 Apr 2004 08:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJANo-0008Po-R1 for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 08:11: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 IAA23338 for ; Thu, 29 Apr 2004 08:11:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJANf-00010U-3X for mmusic@ietf.org; Thu, 29 Apr 2004 08:11:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAMm-0000ph-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:10:12 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BJAMD-0000cZ-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:09:37 -0400 Received: from vpn6 ([130.209.254.6]:58603) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BJALl-0006me-00; Thu, 29 Apr 2004 13:09:09 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <027772EE-99D6-11D8-998D-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit Cc: , From: Colin Perkins Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 13:09:05 +0100 To: Rod.Walsh@nokia.com X-Mailer: Apple Mail (2.613) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Rod, Can you remind us, briefly, what sort of data is conveyed in a FLUTE session? If it's always a single data format, could we not simply mandate that the MIME type and sub-type are signalled in the SDP "m=" line as the and respectively? Colin On 29 Apr 2004, at 12:13, Rod.Walsh@nokia.com wrote: > Thanks Magnus > > One thing to make clear on the media type with FLUTE: I'm happy with > anything that's simple and works. (I just want to check that the > reasoning behind whatever media types are allowed for FLUTE usage are > solid enough so we don't need to rake over the question many times.) > > I Agree that "application" is the natural fit for "FLUTE > applications". We do need to answer 2 questions though: > 1. do we need to specify which media types are allowed? (if not, then > we allow all) > 2. do we need to exclude certain ones? (like the unregistered ones, > and how does this impact the SDP spec?) > > --- --- --- --- > > A quick trawl through RFC2045 found me: > > type := discrete-type / composite-type > discrete-type := "text" / "image" / "audio" / "video" / > "application" / extension-token > composite-type := "message" / "multipart" / extension-token > extension-token := ietf-token / x-token > ietf-token := standards-track RFC and registered > with IANA.> > x-token := no intervening white space, by any token> > > RFC2046 kindly explains these media types: "text", "image", "audio", > "video", "application", "multipart" and "message". > > I'm coming to the opinion that we can allow any of the media types in > a FLUTE "m line". Naturally any impementation would have to adhere to > the media type definitions: a FLUTE channel (given by an m line) would > only deliver files of the described media type (to ensure no impact on > multi-channel congestion control schemes, I supect this is practically > the same as saying the media type will be the same for the whole > session). > > So this would mean: > * you may use the application type for any file typess delivered and > rendered to the user by the FLUTE receiver > * you may use the audio type if only audio files are delivered and > rendered to the user by the FLUTE receiver > * you may use the video type if only video files are delivered and > rendered to the user by the FLUTE receiver > etc... > > So, for all but the most specialised FLUTE implementations, we'd > expect the "application" media type. This may be as much as needs to > be said in a "SDP for FLUTE" I-D. > > --- this draws a line under my comments on "one or many media types > allowed" --- > > The issue about allowing the use of "data" and "control" is that SDP > defines them so their use would be expected, but IANA has not > registered them. Any idea why on earth these are not registered? Since > SDP makes it clear that it's minimal set is to be rarely extended, > surely the use of data and control is totally fine with SDP, > regardless of the IANA registration? > > The issue about allowing the use of "message" and "multipart" is that > SDP does not define them but IANA has them registered. sdp-new text > makes it clear that no further RFC is needed for these existing MIME > top level types to be used - but what is actually needed (anything?) > is unclear. (This is more academic interest than me having a real > need). > > --- now on when "data" might be prefered over "applciation" --- > > SDP gave me the impression that "application" is suitable where 'the > receiver renders the content to the user directly' and "data" is > suitable where 'the receiver does not directly render the content to > the user' (e.g. where the FLUTE receiver and media player are seperate > applications): > ...The difference between "application" > and "data" is that the former is a media flow such as whiteboard > information, and the latter is bulk-data transfer such as > multicasting of program executables which will not typically be > displayed to the user. > > So the example of "m=data..." was based on trying to do what the spec > asks for (not on any strong preference) and was not intended to > exculude "m=application...". > > --- --- --- --- > > Since the quantity of text may have made this unclear, here's the > bottom line: > * Practically anything if fine for me, including "application" only > * I want strong arguments for the way we go so that we don't need to > re-enter this issue > > Cheers, Rod. > > PS Yep, AVT was a typo for AVP - oops _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 09:46:59 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01686 for ; Thu, 29 Apr 2004 09:46:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBeY-0003MH-VH for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWcYd012907 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBUG-0006Hg-Ab for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:22:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29891 for ; Thu, 29 Apr 2004 09:21:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBU5-0004cJ-P2 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:21:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBSc-0004Bq-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:20:18 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBQq-0003gB-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:18:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBEx-0001E0-7V; Thu, 29 Apr 2004 09:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAoc-0006KE-Nc for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 08:38: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 IAA25375 for ; Thu, 29 Apr 2004 08:38:51 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAoS-0007lv-Kn for mmusic@ietf.org; Thu, 29 Apr 2004 08:38:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAml-0007EH-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:37:04 -0400 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1BJAlE-0006p0-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:35:28 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCZOJ07949; Thu, 29 Apr 2004 15:35:24 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 15:35:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TCZROV006956; Thu, 29 Apr 2004 15:35:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00tftPib; Thu, 29 Apr 2004 15:35:26 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TCZ7H07657; Thu, 29 Apr 2004 15:35:07 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:35:01 +0300 Received: from esebe024.NOE.Nokia.com ([172.21.138.125]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:35:00 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe024.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 15:34:59 +0300 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] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 15:35:00 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQt4yBVGzfLmF+mQ9SPDCRM7IGRowAARDOg To: Cc: , X-OriginalArrivalTime: 29 Apr 2004 12:34:59.0835 (UTC) FILETIME=[62E884B0:01C42DE6] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Colin FLUTE transports "files". Potentially any file formats. It is likely that some applications (server and client) will be used for = homogeneous content where every file is of exactly the same type. (In = this case, signalling file content type as the + is fine = IMHO). However, we expect that in most cases FLUTE will carry more than one = (and sometimes very many) content/file types. So only "application" or = "data" media types are generic enough for the bulk of cases. (And then = signalling a list of file types would be done otherwise if it is = necessary for capability or content selection or purchase - I daren't = say more for fear of opening the data model can of worms :) Apart from the IANA registration status of "data", the choice between = "application" and "data" seems open to interpretation according to SDP = (my earlier email said about as much as I have to say on why). Any = opinions on data vs application vs either? Cheers, Rod. > -----Original Message----- > From: ext Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, April 29, 2004 3:09 PM > To: Walsh Rod (Nokia-NRC/Tampere) > Cc: magnus.westerlund@ericsson.com; mmusic@ietf.org > Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs >=20 >=20 >=20 > Rod, >=20 > Can you remind us, briefly, what sort of data is conveyed in a FLUTE=20 > session? If it's always a single data format, could we not simply=20 > mandate that the MIME type and sub-type are signalled in the SDP = "m=3D"=20 > line as the and respectively? >=20 > Colin >=20 ... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 09:47:56 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01794 for ; Thu, 29 Apr 2004 09:47: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 1BJBet-0003Wu-M9 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDWxn9013554 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:32:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBZW-0007yf-Ul for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:27:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00498 for ; Thu, 29 Apr 2004 09:27:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBZM-0006H7-Fb for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:27:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBYa-00061C-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:26:28 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBXe-0005jv-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:25:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBFJ-0001QE-JE; Thu, 29 Apr 2004 09:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJAtl-0008Nj-Lr for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 08:44: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 IAA25961 for ; Thu, 29 Apr 2004 08:44:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJAtb-0001Zu-GT for mmusic@ietf.org; Thu, 29 Apr 2004 08:44:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJAsa-0001KI-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:43:04 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BJArY-0000p0-00 for mmusic@ietf.org; Thu, 29 Apr 2004 08:42:00 -0400 Received: from vpn14 ([130.209.254.14]:58926) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BJAr7-00074o-00; Thu, 29 Apr 2004 13:41:33 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8A0C6EF7-99DA-11D8-998D-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit Cc: , From: Colin Perkins Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 13:41:30 +0100 To: X-Mailer: Apple Mail (2.613) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, On 29 Apr 2004, at 13:35, wrote: > FLUTE transports "files". Potentially any file formats. > > It is likely that some applications (server and client) will be used > for homogeneous content where every file is of exactly the same type. > (In this case, signalling file content type as the + is > fine IMHO). Okay. > However, we expect that in most cases FLUTE will carry more than one > (and sometimes very many) content/file types. So only "application" or > "data" media types are generic enough for the bulk of cases. (And then > signalling a list of file types would be done otherwise if it is > necessary for capability or content selection or purchase - I daren't > say more for fear of opening the data model can of worms :) How does the receiver know the contents of the FLUTE session if more than one file type is transported? Are you trying to signal that list in SDP? Or is it picked up from the FLUTE session somehow? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 09:59:34 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02519 for ; Thu, 29 Apr 2004 09:59: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 1BJC0u-0001Rn-CJ for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:55:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDti6P005558 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBgI-0004IM-NO for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:34: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 JAA01171 for ; Thu, 29 Apr 2004 09:34:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBg8-0000S1-5R for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBf7-00007j-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:33:14 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBe9-0007aw-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBRN-0005f8-OX; Thu, 29 Apr 2004 09:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBF3-0001I9-JB for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 09:06: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 JAA28173 for ; Thu, 29 Apr 2004 09:06:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBEt-0000NG-8P for mmusic@ietf.org; Thu, 29 Apr 2004 09:06:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBDu-00008m-00 for mmusic@ietf.org; Thu, 29 Apr 2004 09:05:07 -0400 Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx with esmtp (Exim 4.12) id 1BJBCw-0007gg-00 for mmusic@ietf.org; Thu, 29 Apr 2004 09:04:06 -0400 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i3TD49Ah028893 for ; Thu, 29 Apr 2004 15:04:09 +0200 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Apr 2004 15:04:09 +0200 Received: from ericsson.com (research-1fd0e1.ki.sw.ericsson.se [147.214.34.138]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id J5CDLM7S; Thu, 29 Apr 2004 15:04:12 +0200 Message-ID: <4090FD49.1050303@ericsson.com> Date: Thu, 29 Apr 2004 15:04:09 +0200 X-Sybari-Trust: fe6c2bd5 c38aee8b 00db2f9f 00000138 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: sv, en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs References: <8A0C6EF7-99DA-11D8-998D-000A957FC5F2@csperkins.org> In-Reply-To: <8A0C6EF7-99DA-11D8-998D-000A957FC5F2@csperkins.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2004 13:04:09.0270 (UTC) FILETIME=[75A71D60:01C42DEA] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, After having thought of this, what I think for FLUTE is that it actually defines its own registry for applications. There will be need for different applications to be identified. So if someone is announcing a FLUTE delivery session one can also instantiate the correct receiver behaviour. Different applications may also go as far as redefining what it expects the FDT to contain. So I think one should consider making definition of how the format specific part of the M line should be used. In that one can also consider if FLUTE is always one type of media, or if the it really is necessary to identify the media type already in the SDP. In my view I think we can consider any instantiation of the FLUTE delivery to be for the purpose of an application. Therefore use the "application" media type. Then the application itself is identified in the FMT part of the m= line. A registry for applications is then established so that one can determine the application. And it is the applications that defines what type of files are actually sent within the FLUTE delivery session. How does that sound? Cheers Magnus Colin Perkins wrote: > Hi, > > On 29 Apr 2004, at 13:35, wrote: > >> FLUTE transports "files". Potentially any file formats. >> >> It is likely that some applications (server and client) will be used >> for homogeneous content where every file is of exactly the same type. >> (In this case, signalling file content type as the + is >> fine IMHO). > > > Okay. > >> However, we expect that in most cases FLUTE will carry more than one >> (and sometimes very many) content/file types. So only "application" or >> "data" media types are generic enough for the bulk of cases. (And then >> signalling a list of file types would be done otherwise if it is >> necessary for capability or content selection or purchase - I daren't >> say more for fear of opening the data model can of worms :) > > > How does the receiver know the contents of the FLUTE session if more > than one file type is transported? Are you trying to signal that list in > SDP? Or is it picked up from the FLUTE session somehow? > -- 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 Apr 29 10:06:00 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03040 for ; Thu, 29 Apr 2004 10:06:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJC1f-0001m6-3w for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:56:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TDuVeW006817 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 09:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBl8-0005ns-KL for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 09:39: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 JAA01468 for ; Thu, 29 Apr 2004 09:39:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBky-0001i7-1D for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:39:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBk4-0001Sg-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:38:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJBjB-0001EP-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 09:37:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBe4-00030I-Iw; Thu, 29 Apr 2004 09:32:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJBKU-0002kP-HY for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 09:11: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 JAA28520 for ; Thu, 29 Apr 2004 09:11:46 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJBKK-0001oQ-5J for mmusic@ietf.org; Thu, 29 Apr 2004 09:11:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJBI4-00018g-00 for mmusic@ietf.org; Thu, 29 Apr 2004 09:09:25 -0400 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1BJBHR-0000tu-00 for mmusic@ietf.org; Thu, 29 Apr 2004 09:08:45 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TD8kv27296; Thu, 29 Apr 2004 16:08:46 +0300 (EET DST) X-Scanned: Thu, 29 Apr 2004 16:08:32 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3TD8WOP014688; Thu, 29 Apr 2004 16:08:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00y0S4XZ; Thu, 29 Apr 2004 16:06:00 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3TD60H23400; Thu, 29 Apr 2004 16:06:00 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 16:05:57 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 29 Apr 2004 16:05:58 +0300 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] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 16:05:57 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQt54Vv/e3KQeqLS6qnJcCEp0n6iAAAkSjg To: Cc: , X-OriginalArrivalTime: 29 Apr 2004 13:05:58.0331 (UTC) FILETIME=[B6A880B0:01C42DEA] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > How does the receiver know the contents of the FLUTE session if more=20 > than one file type is transported? Are you trying to signal that list=20 > in SDP? Or is it picked up from the FLUTE session somehow? It can be picked up from the FLUTE session. One or more FDT Instances = describe the files and include the MIME type. FDT (File Decription = Table) Instances are XML objects/files. I not convinced that it is necessary to provide a list of several file = types of the session for two reasons: the MIME types are available from = FLUTE; and in some advanced media discrovery system (IMG stuff) the = client would select the files, most likely already needing to knwo MIME = types then (why what you can't use?). But I'm open to ideas! Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 12:40:56 2004 Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13024 for ; Thu, 29 Apr 2004 12:40:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJETE-0002qg-El for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TGX8ij010948 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 12:33:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJE0Y-0000E4-2B for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 12:03: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 MAA10964 for ; Thu, 29 Apr 2004 12:03:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJE0T-0000nc-FD for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 12:03:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDzT-0000X5-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 12:02:24 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJDyi-0000Gx-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 12:01:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDph-0005qy-34; Thu, 29 Apr 2004 11:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJDPg-00072d-N8 for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 11:25:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08984 for ; Thu, 29 Apr 2004 11:25:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJDPc-0006AK-AA for mmusic@ietf.org; Thu, 29 Apr 2004 11:25:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJDOn-0005uh-00 for mmusic@ietf.org; Thu, 29 Apr 2004 11:24:29 -0400 Received: from dns.packetdesign.com ([65.192.41.10] helo=mailman.packetdesign.com) by ietf-mx with esmtp (Exim 4.12) id 1BJDO8-0005dQ-00 for mmusic@ietf.org; Thu, 29 Apr 2004 11:23:48 -0400 Received: from packetdesign.com (main-fw-eth1.packetdesign.com [192.168.0.254]) by mailman.packetdesign.com (8.12.8/8.12.8) with ESMTP id i3TFNDWe020828; Thu, 29 Apr 2004 08:23:14 -0700 (PDT) (envelope-from casner@acm.org) Date: Thu, 29 Apr 2004 08:23:13 -0700 (PDT) From: Stephen Casner To: Rod.Walsh@nokia.com cc: mmusic@ietf.org Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs In-Reply-To: Message-ID: <20040429075950.H76585@oak.packetdesign.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, 28 Apr 2004 Rod.Walsh@nokia.com wrote: > One of the implications of wanting an SDP description for FLUTE > (previous email) is that we will need a protocol ID for the m > line. Although this seems trivial to me, I would like to know if > anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT", > "udp" and "TCP" are existing examples) > > So for example, you'd get an media field looking like this: > m=data 12345 UDP/FLUTE 0 > > (Any reason not to prefer "FLUTE/UDP"?) The order of RTP/AVP is the order of decreasing significance. That is, AVP is a particular specialization (profile) of RTP. There are multiple second components that follow the first, but it is unlikely that the symbol "AVP" will follow anything other than "RTP" and still have the same meaning. In the case of UDP and FLUTE, FLUTE is one of several protocols that can be layered after UDP in the packet. FLUTE is a specialization of the use of UDP. So I prefer UDP/FLUTE. (I also prefer IP/TCP, because it reflects layering order, but the common terminology is TCP/IP because TCP is considered layered "over" IP. I suppose this is another big-endian / little-endian issue.) Note that in the case of "RTP/AVP", the use of UDP is implied. To use RTP over another lower-layer protocol requires a new term, such as DCCP/RTP/AVP. If FLUTE would only be used with UDP in this context, then UDP could be implicit for FLUTE as well. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Apr 29 15:59:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24807 for ; Thu, 29 Apr 2004 15:59:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHXm-0004Re-0S for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 15:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJo1CP017084 for mmusic-archive@odin.ietf.org; Thu, 29 Apr 2004 15:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJHEq-0007Bg-7r for mmusic-web-archive@optimus.ietf.org; Thu, 29 Apr 2004 15:30: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 PAA22923 for ; Thu, 29 Apr 2004 15:30:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJHEj-0004pw-LT for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 15:30:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJHDj-0004lr-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 15:29:19 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJHCk-0004gZ-00 for mmusic-web-archive@ietf.org; Thu, 29 Apr 2004 15:28:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH97-0005d2-TV; Thu, 29 Apr 2004 15:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGls-0006ra-E3 for mmusic@optimus.ietf.org; Thu, 29 Apr 2004 15:00: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 PAA19780 for ; Thu, 29 Apr 2004 15:00:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJGlm-0002qy-5Y for mmusic@ietf.org; Thu, 29 Apr 2004 15:00:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJGku-0002o5-00 for mmusic@ietf.org; Thu, 29 Apr 2004 14:59:33 -0400 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1BJGkH-0002jj-00 for mmusic@ietf.org; Thu, 29 Apr 2004 14:58:53 -0400 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63922 helo=[192.168.0.5]) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:RC4-SHA:128) (Exim 4.04) id 1BJGjq-0000WH-00; Thu, 29 Apr 2004 19:58:26 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <53C64198-9A0B-11D8-BB1F-000A957FC5F2@csperkins.org> Content-Transfer-Encoding: 7bit Cc: , From: Colin Perkins Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs Date: Thu, 29 Apr 2004 19:30:44 +0100 To: Rod.Walsh@nokia.com X-Mailer: Apple Mail (2.613) 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On 29 Apr 2004, at 14:05, Rod.Walsh@nokia.com wrote: >> How does the receiver know the contents of the FLUTE session if more >> than one file type is transported? Are you trying to signal that list >> in SDP? Or is it picked up from the FLUTE session somehow? > > It can be picked up from the FLUTE session. One or more FDT Instances > describe the files and include the MIME type. FDT (File Decription > Table) Instances are XML objects/files. > > I not convinced that it is necessary to provide a list of several file > types of the session for two reasons: the MIME types are available > from FLUTE; and in some advanced media discrovery system (IMG stuff) > the client would select the files, most likely already needing to knwo > MIME types then (why what you can't use?). But I'm open to ideas! It's beginning to sound like "m=data 49000 FLUTE/UDP" would be the right way to go, letting the application pick up the media types from the FLUTE session. Unfortunately, though, the parameter is mandatory in SDP "m=" lines. Unless there is something specific to FLUTE that could be used, we might need a dummy value? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 30 06:01:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07433 for ; Fri, 30 Apr 2004 06:01:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUnU-0007ft-JC for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 05:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U9x8S8029501 for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 05:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUhB-0006lA-Hj for mmusic-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 05:52: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 FAA07007 for ; Fri, 30 Apr 2004 05:52:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJUh4-0002fC-Ew for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 05:52:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUfw-0002Qq-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 05:51:20 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJUfC-0002E8-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 05:50:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUa1-0005pd-7v; Fri, 30 Apr 2004 05:45:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUWx-0005PG-48 for mmusic@optimus.ietf.org; Fri, 30 Apr 2004 05:42: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 FAA06409 for ; Fri, 30 Apr 2004 05:41:59 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJUWq-0000nN-1I for mmusic@ietf.org; Fri, 30 Apr 2004 05:41:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUW3-0000dF-00 for mmusic@ietf.org; Fri, 30 Apr 2004 05:41:07 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJUVN-0000Qi-00 for mmusic@ietf.org; Fri, 30 Apr 2004 05:40:25 -0400 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U9eSH03162; Fri, 30 Apr 2004 12:40:28 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 12:40:03 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i3U9e3VI005992; Fri, 30 Apr 2004 12:40:03 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 001pK4pL; Fri, 30 Apr 2004 12:40:02 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3U9drH06424; Fri, 30 Apr 2004 12:39:53 +0300 (EET DST) Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 12:39:50 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 12:39:50 +0300 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] And one more SDP-quiz question on protocol IDs Date: Fri, 30 Apr 2004 12:39:49 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQt6sNsml56hojWQ8+gCQhQZJsAUgAnY9bA To: Cc: X-OriginalArrivalTime: 30 Apr 2004 09:39:50.0919 (UTC) FILETIME=[1584F170:01C42E97] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > ... Therefore use the "application" media=20 > type. Then the application itself is identified in the FMT=20 > part of the=20 > m=3D line.=20 >> How does that sound? Sounds good. Naturally, the FMT could be "null" to indicate that the application is = going to need some other means to work out session content types (e.g. = FDT, "IMG service description", etc.)=20 > A registry for applications is then established so=20 > that one can=20 > determine the application. And it is the applications that=20 > defines what=20 > type of files are actually sent within the FLUTE delivery session. >=20 > How does that sound? Sounds like I need to be educated about how to deal with these = registrations :) Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 30 06:24:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08502 for ; Fri, 30 Apr 2004 06:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJVAM-0003Qz-0b for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 06:22:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UAMj9w013197 for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 06:22:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJV5h-00030n-KC for mmusic-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 06:17: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 GAA08228 for ; Fri, 30 Apr 2004 06:17:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJV5a-0006rJ-Gf for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 06:17:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJV4a-0006g2-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 06:16:48 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJV3Z-0006PK-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 06:15:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJUv7-0000Hf-8h; Fri, 30 Apr 2004 06: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 1BJUqM-00087H-L8 for mmusic@optimus.ietf.org; Fri, 30 Apr 2004 06: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 GAA07465 for ; Fri, 30 Apr 2004 06:02:02 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJUqF-0004Ho-FV for mmusic@ietf.org; Fri, 30 Apr 2004 06:01:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJUpO-00046c-00 for mmusic@ietf.org; Fri, 30 Apr 2004 06:01:06 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJUoq-0003wg-00 for mmusic@ietf.org; Fri, 30 Apr 2004 06:00:32 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UA0ZH23401; Fri, 30 Apr 2004 13:00:35 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 13:00:13 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3UA0DKp028197; Fri, 30 Apr 2004 13:00:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ekZqEd; Fri, 30 Apr 2004 13:00:12 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UA06H21244; Fri, 30 Apr 2004 13:00:06 +0300 (EET DST) Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 13:00:04 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 13:00:03 +0300 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] And one more SDP-quiz question on protocol IDs Date: Fri, 30 Apr 2004 13:00:02 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQuHBgOOmhHuvG1SQmNI/rjo0wacQAewA2w To: Cc: , X-OriginalArrivalTime: 30 Apr 2004 10:00:03.0804 (UTC) FILETIME=[E87481C0:01C42E99] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > It's beginning to sound like "m=3Ddata 49000 FLUTE/UDP" would be the=20 > right way to go, letting the application pick up the media types from=20 > the FLUTE session. Sounds good. My lack of preference over application and data should be = pretty clear now :) I see that in the case of a data carousel kind of application (which = user application request files from locally) "data" fits well. And in = the media player application (where the player also includes the FLUTE = protocol, as many already have HTTP/html) then "applciation" fits. Since = these are receiver specific and since, in some situations, the sender = may not have a good idea in advance that all receiver applications are = of a certain sort - coming down hard on either only data or only = application may be ticky. As far as I see "application" is great for my = main use cases, but I suspect this may not be true of everyone. > Unfortunately, though, the parameter is mandatory in SDP "m=3D"=20 > lines. Unless there is something specific to FLUTE that could=20 > be used,=20 > we might need a dummy value? Makes sense "dummy" =3D "null". Cheers, Rod. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Apr 30 07:23:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10760 for ; Fri, 30 Apr 2004 07:23:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJW5K-0002Hk-Vg for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 07:21:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3UBLc0L008782 for mmusic-archive@odin.ietf.org; Fri, 30 Apr 2004 07:21:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJW4g-0002B8-BT for mmusic-web-archive@optimus.ietf.org; Fri, 30 Apr 2004 07:20: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 HAA10605 for ; Fri, 30 Apr 2004 07:20:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJW4f-0001Qn-R3 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 07:20:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJW3h-0001FW-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 07:19:57 -0400 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BJW2f-0000zB-00 for mmusic-web-archive@ietf.org; Fri, 30 Apr 2004 07:18:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJVwx-0001Ef-Cj; Fri, 30 Apr 2004 07:12:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJVrC-0000Yr-QE for mmusic@optimus.ietf.org; Fri, 30 Apr 2004 07: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 HAA10306 for ; Fri, 30 Apr 2004 07:06:58 -0400 (EDT) From: Rod.Walsh@nokia.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BJVr5-00074q-1B for mmusic@ietf.org; Fri, 30 Apr 2004 07:06:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJVqA-0006vj-00 for mmusic@ietf.org; Fri, 30 Apr 2004 07:05:59 -0400 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1BJVpe-0006ml-00 for mmusic@ietf.org; Fri, 30 Apr 2004 07:05:26 -0400 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UB5TH06642; Fri, 30 Apr 2004 14:05:29 +0300 (EET DST) X-Scanned: Fri, 30 Apr 2004 14:05:26 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i3UB5Q9B017479; Fri, 30 Apr 2004 14:05:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00DmMocw; Fri, 30 Apr 2004 14:05:24 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i3UB5IH09814; Fri, 30 Apr 2004 14:05:18 +0300 (EET DST) Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 14:05:10 +0300 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Apr 2004 14:05:10 +0300 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] And one more SDP-quiz question on protocol IDs Date: Fri, 30 Apr 2004 14:05:09 +0300 Message-ID: Thread-Topic: [MMUSIC] And one more SDP-quiz question on protocol IDs Thread-Index: AcQt/lIFsA95VAdsTzykkO2DNz6sagAnQL9w To: Cc: X-OriginalArrivalTime: 30 Apr 2004 11:05:10.0276 (UTC) FILETIME=[00E4D440:01C42EA3] 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: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Steve Thanks for the comment. I understand both arguments and am pretty sure = either of FLUTE/UDP and UDP/FLUTE would do the job nicely UDP/FLUTE seems closer to the RTP/AVP precedent. (Anyone know if there = was a big-endian motivation behind this selection for SDP in the first = place?) FLUTE/UDP seems to show the right emphasis: FLUTE. For The receiver and = application capability, the client is primarily concerned that it is = using FLUTE (UDP or foo follows after that). This is also true for = RTP/AVP, clients are first interested in RTP, then UDP and AVP comes = next (since I've never implemented an RTP client, please put me straight = if I blundered on this). As long as we choose one, and not both ways, then I'm happy. The reason for not just suggesting FLUTE (without the /UDP) is the = potential for some theoretical future FLUTE to work over other than UDP = (LCT and ALC bind us to UDP for now, but make it clear that this may not = always be the case). Although FLUTE/TCP (foo/FLUTE, FLUTE/foo etc) would = be contrary to the current LCT, it should not cause problems for FLUTE = alone (FLUTE/TCP seems to fit into "congestion control scenario (c)" of = =A74 as TCP would provide the CC which is "no more aggressive than TCP" = :) I think this is more a discussion for LCT transition to PS (or LCTv2) = in RMT, so let me put the lid back on that can of worms for now. Cheers, Rod. > -----Original Message----- > From: casner@packetdesign.com=20 > [mailto:casner@packetdesign.com]On Behalf > Of ext Stephen Casner > Sent: Thursday, April 29, 2004 6:23 PM > To: Walsh Rod (Nokia-NRC/Tampere) > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs >=20 >=20 >=20 > On Wed, 28 Apr 2004 Rod.Walsh@nokia.com wrote: >=20 > > One of the implications of wanting an SDP description for FLUTE > > (previous email) is that we will need a protocol ID for the m > > line. Although this seems trivial to me, I would like to know if > > anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT", > > "udp" and "TCP" are existing examples) > > > > So for example, you'd get an media field looking like this: > > m=3Ddata 12345 UDP/FLUTE 0 > > > > (Any reason not to prefer "FLUTE/UDP"?) >=20 > The order of RTP/AVP is the order of decreasing significance. That > is, AVP is a particular specialization (profile) of RTP. There are > multiple second components that follow the first, but it is unlikely > that the symbol "AVP" will follow anything other than "RTP" and still > have the same meaning. >=20 > In the case of UDP and FLUTE, FLUTE is one of several protocols that > can be layered after UDP in the packet. FLUTE is a specialization of > the use of UDP. So I prefer UDP/FLUTE. >=20 > (I also prefer IP/TCP, because it reflects layering order, but the > common terminology is TCP/IP because TCP is considered layered "over" > IP. I suppose this is another big-endian / little-endian issue.) >=20 > Note that in the case of "RTP/AVP", the use of UDP is implied. To use > RTP over another lower-layer protocol requires a new term, such as > DCCP/RTP/AVP. >=20 > If FLUTE would only be used with UDP in this context, then UDP could > be implicit for FLUTE as well. >=20 > -- Steve >=20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic