From exim@www1.ietf.org Mon Dec 1 20:08:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14928 for ; Mon, 1 Dec 2003 20:08:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQz1K-0001Hl-Kx for mmusic-archive@odin.ietf.org; Mon, 01 Dec 2003 20:08:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2186Mb004928 for mmusic-archive@odin.ietf.org; Mon, 1 Dec 2003 20:08:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQz1J-0001HH-M7 for mmusic-web-archive@optimus.ietf.org; Mon, 01 Dec 2003 20: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 UAA14920 for ; Mon, 1 Dec 2003 20:07:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQz1H-0006qP-00 for mmusic-web-archive@ietf.org; Mon, 01 Dec 2003 20:08:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AQz1H-0006qL-00 for mmusic-web-archive@ietf.org; Mon, 01 Dec 2003 20:08:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQz1F-0001GF-Cf; Mon, 01 Dec 2003 20:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQz0U-0000yP-1I for mmusic@optimus.ietf.org; Mon, 01 Dec 2003 20:07:14 -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 UAA14908; Mon, 1 Dec 2003 20:06:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQz0R-0006q1-00; Mon, 01 Dec 2003 20:07:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQz0R-0006pr-00; Mon, 01 Dec 2003 20:07:11 -0500 Received: from mbaugher-w2k07.cisco.com (sjc-vpn1-875.cisco.com [10.21.99.107]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hB216brY013145; Mon, 1 Dec 2003 17:06:38 -0800 (PST) Message-Id: <6.0.0.22.2.20031201163158.03cb0a28@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Mon, 01 Dec 2003 17:06:34 -0800 To: Kumiko Ono From: Mark Baugher Cc: mary.barnes@nortelnetworks.com, tachimoto.shinya@lab.ntt.co.jp, sipping@ietf.org, mmusic@ietf.org, cyrus@ntt-at.com, fandreas@cisco.com, dwing@cisco.com In-Reply-To: <2EC3B401E99BAEono.kumiko@lab.ntt.co.jp> References: <6.0.0.22.2.20031125160613.03fd89d8@mira-sjc5-6.cisco.com> <2EC3B401E99BAEono.kumiko@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Re: e2m, m2m security drafts Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , hi Kumiko-san, At 01:44 AM 11/26/2003, Kumiko Ono wrote: >Hi Mark, > >Thanks for your comments. Inline- > > wrote: > >1. Section 5.1 of > >http://www.ietf.org/internet-drafts/draft-ono-sipping-end2middle-security- > >00.txt > >shows an example of an encrypted SDP in an INVITE but the key to this > >encrypted SDP is selectively shared with some proxies so they can view the > >encrypted data. There is undoubtedly some information in the SDP that a > >proxy needs to view and some that it does not need to view, such as the > >end-to-end keying material. Can we accommodate this requirement in the > >current proposals? That is, could we keep the keying material encrypted > >end-to-end while allowing a proxy to view other parts of the SDP message? > >Yes, definitely. >Section 3.1 of the requirement draft says that >"The solution MUST work even with SIP end-to-end encryption for >confidentiality service enabled". > >To clarify this requirement, I would say: >- It MUST work even with end-to-end encryption of some data. > That is, encrypted data can be shared with the end user and selected >proxies. >- It MUST NOT violate end-to-end encryption when the encrypted data does >not need to be shared with any proxies. Thanks. One more clarification, please. By "encrypted data" (which in my case is the SDP crypto attribute that carries keying material and parameters), do you mean the entire SDP message or can it be restricted to selected lines of the SDP message? Will it be possible to share all needed information in the SDP message *except* the security descriptions attribute in the SDP message? > > >2. Have you considered writing a core specification like RFC 1847 and allow > >for one or more profiles such as S/MIME (today) and PGP MIME (in the > >future)? I understand that S/MIME is the designated SIP solution, but it > >might be wise to allow for future extensions. > >Hmm... in the future, such extensions might be needed. >However, I have not considered that yet. >I think there are still more work to use S/MIME practically in SIP. Yes, I think so, too. It is also possible that an X.509 PKI is found to be not the most deployable solution for global telephony. Hence, my point about accommodating different structures in the future. Today, there are S/MIME and PGP MIME. A core specification would enable one to apply what you develop for one security specification (S/MIME) to others (PGP MIME, etc). To do this would require one to take out the features of the e2m and m2m security that are general to all secure multipart specifications, put these features into one document and then put the features that are specific to S/MIME in a second document. Just a thought. I can understand how this seems less important in the context of the current SIP specification. But I am a bit skeptical about the future of X.509 PKI and expect that other approaches might be tried in the future. Regarding S/MIME, do you intend to give a PKI design for the solution? That is, who is going to design the PKI that is needed for e2m security? I have some more questions on the I-Ds. I won't list all of them and won't present them in any particular order. 3. In the requirements document and in your previous I-D, I read that "it is not appropriate for the UA on the opposite-side to have knowledge of the public key certificate of the proxy server on the originating network." Number 7, p. 7 of the requirements I-D. Why is the public key protected in this way? 4. Requirements Number 4 and 5 on p. 7 state that it should allow a UA to discover which proxy needs to view some data and what they need to view. This sounds like it can add a lot of time to call establishment. I'm curious to know how this can be done without a very large number of exchanges taking place prior to establishing the call. 5. The words "trusted" and "partially trusted" appear in the I-D. The word "trusted" to me always begs the question "trusted to do what?" Since I don't have a clear idea about what you mean by "trusted," it's hard to tell what you mean by "partially trusted." Precision is important here. Have you considered doing an "assets, risks and threats" analysis on the information to identify the particular assets in the SIP message, such as caller, callee, SDP message fields, etc.? What are the risks to these assets? And who might try to gain unauthorized read or write access to them? regards, Mark >Thanks a lot, > >Kumiko > >-- >Kumiko Ono >NTT Network Service Systems Labs. >Tel +81 422 59 4508/Fax +81 422 60 4012 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 2 03:52:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08643 for ; Tue, 2 Dec 2003 03:52:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GN-0003XP-NP for mmusic-archive@odin.ietf.org; Tue, 02 Dec 2003 03:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB28q767013598 for mmusic-archive@odin.ietf.org; Tue, 2 Dec 2003 03:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GM-0003Wv-Jl for mmusic-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 03:52: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 DAA08621 for ; Tue, 2 Dec 2003 03:51:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6GJ-0003fb-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 03:52:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR6GJ-0003fY-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 03:52:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6GJ-0003W8-7b; Tue, 02 Dec 2003 03:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR6Fy-0003VX-PG for mmusic@optimus.ietf.org; Tue, 02 Dec 2003 03:51:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08618 for ; Tue, 2 Dec 2003 03:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR6Fw-0003fR-00 for mmusic@ietf.org; Tue, 02 Dec 2003 03:51:40 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1AR6Fv-0003fO-00 for mmusic@ietf.org; Tue, 02 Dec 2003 03:51:39 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB28pYI2001707; Tue, 2 Dec 2003 09:51:39 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW89SM3P; Tue, 2 Dec 2003 09:51:57 +0100 Message-ID: <3FCC5294.8040207@ericsson.com> Date: Tue, 02 Dec 2003 09:51:32 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation References: <1066800352.27652.3.camel@jamba> In-Reply-To: <1066800352.27652.3.camel@jamba> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, Here is my comments on your write-up. I think one should be clearer on separating the two cases where one can "negotiate" transport parameters: 1. Initially when a stream is setup 2. Changing transport parameters during a session. See more inline. I have not removed any of Geetha's mail to make it easy to read her initial text in full, thus it is a bit long. Geetha Srikantan wrote: > Hello everyone, > > Here is the promised write-up on RTSP transport negotiation..sorry for > the delay. If there is agreement on the content of this note, I can > write up text for the RTSP draft. > > thanks > geetha > > > Topic: RTSP Transport negotiation using SETUP during play state. > > Introduction > > The RTSP specification allows for negotiation of transport parameters > via the SETUP method, while the RTSP session is in play state. The > transport parameters that can be negotiated and the exact form of this > negotiation is under-specified in the RTSP documents. This note is an > attempt to clarify some of the issues around transport negotiation for > inclusion in the ongoing revision of RTSP. > > The recent interest in mobility for RTSP implementations also impacts > transport parameters used by the session. For instance, a wireless > RTSP client could be assigned a new IP address, or may experience > change of network characteristics, while it is in the midst of a RTSP > session. These issues are also addressed in this note. > > > Outline: > > 1. Objective > 2. Enumeration of all Transport Parameters > 3. Transport Parameters Excluded from Negotiation > 4. Negotiable Transport Parameters > 5. Impact of Transport Negotiation > 6. Examples > 6.1 Client IP Address Changes > 6.2 UDP -> TCP > 6.3 TCP -> UDP > 7. Other transport related changes to RTSP draft > 8. Summary > > > > 1. Objective: > > The main goals of this document are to > * Provide an enumeration of transport parameters. > * Identify transport parameters that cannot be negotiated > with minimal impact on other sessions. > * Propose transport parameters that can be negotiated during > play state. > * Determine implications of changing these parameters via a > SETUP request while the session is in play state. > * Provide examples demonstrating transport negotiation. > > > 2. Enumeration of all Transport Parameters > > The following is a list of all transport parameters in the current > RTSP draft. > > unicast/multicast > destination > source > mode (=PLAY) > interleaved > layers (for multicast) > ttl (for multicast > port (for multicast) > client_port (for RTP) > server_port (for RTP) > ssrc (for RTP) > url > You are missing a few and "url" is not a parameter. dest_addr src_addr append Transport protocol and Profile Lower layer transport > > 3. Transport Parameters Excluded from Negotiation > > It is recommended that the following parameters be excluded from the > negotiation process. > > mode > url > unicast/multicast > layers > ttl > ssrc > destination > source > > > As the "mode" parameter is restricted to a single value in the > current draft, it can be excluded. I think that this is a very fundamental parameter if also record is add again in the future. > > As per the recent proposal to not support addition of urls via SETUP > during play state, the "url" parameter can be excluded. I think the Request URL are somewhat out of scope for this discussion, as it actually provides the scope for the negotiation. The Request URL will indicate for the server if the client desires to do: 1. Setup up a new stream (only possible in "init" or "ready" state) 2. Change the transport parameters for a stream. However in both cases the transport parameters can be "negotiated" so this applies for both of them. I just thinks that one must be clear about the different scopes. However in both cases one must include all the parameters one likes to have applied. > > Changing from multicast to unicast based on a single RTSP session's > SETUP, would impact all the other clients accessing the multicast > session. > Several issues need to be considered in this case, including transport > negotiation. Similarly, changing from unicast to multicast also has > implications beyond a single RTSP session. Changes to other > multicast-related parameters, "layers", "ssrc", "ttl" most likely > requires specification beyond transport negotiation. > The recommendation is to *not* specify changing the transport from > "unicast" to "multicast" or vice versa, and also not specify changes > to the "layers" and "ttl" parameters, in this draft. It is recommedned > that negotiation of multicast-related transport parameters should be > deferred to an RTSP-extension document. > > Once an RTSP session has been initiated and the "destination" and > "source" have been established - i.e. a multicast "destination" has > been identified, and the stream "source" has been identified, there > should be no need to change these parameters. It is recommended that > the "destination" and "source" parameters not be negotiated when the > session is in play state. The case of the client IP address change is > signaled in a different manner, outlined in the next section. > I think that SSRC can if not negotiated, at least be changed by the server if deemed necessary, however this is probably not recommended. Transport protocol and profile does seem to belong to this class of parameters that are established initially but then not intended to be changed during a session. > > 4. Negotiable Transport Parameters > > Hence there are three main conditions that require transport > negotiation for unicast: > > * client IP address changes > * client wants to switch transport from UDP -> TCP > * client wants to switch transport from TCP -> UDP > > Changes in the client IP address can be indicated using a new > "client_ip" parameter. Hence the parameters that are impacted by > transport negotiation are: > > client_ip > interleaved > client_port > server_port > I think we should clarify client ip and port with destination address/port. I also think an important parameter to discuss in this context is the lower layer transport. I would think that the transport protocol and profile are not likely to change. > > 5. Impact of Transport Negotiation > > The first column describes the primary change, the second and third > columns describe any secondary transport parameters that MUST or > MAY change as a result of the primary change. > > > Changed MUST MAY > ------- ---- --- > > Client IP address client_ip client_port > server_port > > UDP -> TCP interleaved Server may change > Drop client_port interleaved channel ids > Drop server_port in response. > > TCP -> UDP client_port in request client_ip > server_port in response client_port in response > Drop interleaved > > I think one should clarify that in TCP->UDP changes one must now include (add) a destination port in the request. > > 6. Examples > > 6.1 Client IP Address Changes > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > CSeq: 1 > Content-Type: application/sdp > Content-Length: 164 > > v=0 > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > s=RTSP Session > i=An Example of RTSP Session Usage > a=control:rtsp://foo/twister > t=0 0 > m=audio 0 RTP/AVP 0 > a=control:rtsp://foo/twister/audio > m=video 0 RTP/AVP 26 > a=control:rtsp://foo/twister/video > There shall be a "c=" line somewhere. Then a question, how does the client learn that if this session is multicast that it really is? Is that totally dependent on that the "c=" address is of multicast type? > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=8000-8001 If one would like to have a good example of initial "negotiation" then the client should include multiple transport specs for the server to choose from. > > S->C: RTSP/1.0 200 OK > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=8000-8001; > server_port=9000-9001 > Session: 12345678 In the setup response the server should include a "ssrc" parameter to indicate what SSRC it will use and for which the RTP-Info is valid. > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=8002-8003 > Session: 12345678 > > S->C: RTSP/1.0 200 OK > CSeq: 3 > Transport: RTP/AVP;unicast;client_port=8002-8003; > server_port=9004-9005 > Session: 12345678 > SSRC again. > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 4 > Range: npt=0- > Session: 12345678 > > S->C: RTSP/1.0 200 OK > CSeq: 4 > Session: 12345678 > RTP-Info: url=rtsp://foo/twister/video; > seq=9810092;rtptime=3450012, > url=rtsp://foo/twister/audio;seq=5923;rtptime=22234432 > Range: npt=0-30.76 > > ... now change client IP address .... > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip= client_port=8002-8003;server_port=9004-9005 > Range: npt=5- > Session: 12345678 > The parameter is not "client_ip" it is either "destination" or "dest_addr". As discussed previously the use of Range in the Request makes little sense. > S->C: RTSP/1.0 200 OK > CSeq: 5 > Transport: RTP/AVP;unicast;client_ip=; > client_port=8002-8003;server_port=9004-9005 > RTP-Info: url=rtsp://foo/twister/video; > seq=;rtptime=, > Range: npt=5-30.76 > Session: 12345678 > I also think one should point out why one includes Range here. In regards to the RTP-Info, I think that one should primarily indicate the RTP sequence number in RTP-Info. Using rtptime combined with "Range" might not be the best, because one would normally not intend to change anything in the npt <-> RTP TS binding, as it would cause real problems for a client during playback. > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 6 > Transport:RTP/AVP;unicast;client_ip=; > client_port=8000-8001;server_port=9000-9001 > Range: npt=5- > Session: 12345678 > > S->C: RTSP/1.0 200 OK > CSeq: 6 > Transport: RTP/AVP;unicast;client_ip=; > client_port=8000-8001;server_port=9000-9001 > RTP-Info:url=rtsp://foo/twister/audio; > seq=;rtptime= > Range: npt=5-30.76 > Session: 12345678 > > > > > 6.2 UDP -> TCP > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 > > v=0 > o=- 3262117360 3262117360 IN IP4 0.0.0.0 > s=RTSP Session > c=IN IP4 0.0.0.0 > t=0 0 > a=control:* > a=range:npt=0-10.566000 > m=video 0 RTP/AVP 26 > a=control:rtsp://foo/twister/video > m=audio 0 RTP/AVP 0 > a=control:rtsp://foo/twister/audio > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 > > S->C: RTSP/1.0 200 OK > CSeq: 2 > Session: 12345678 > Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; > server_port=9000-9001 > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 > > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > CSeq: 3 > RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 > Range: npt=0- > Session: 12345678 > > ... now request TCP ... > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/TCP;interleaved=0-1 > > S->C: RTSP/1.0 200 OK > Cseq: 4 > Transport: RTP/AVP/TCP;unicast; > client_ip=;interleaved=0-1 > RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= > Range: npt=0-10.56600 > Session: 12345678 > > > > 6.3 TCP -> UDP > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > CSeq: 1 > > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Content-Length: 230 > Content-Type: application/sdp > Cseq: 1 > > v=0 > o=- 3262117360 3262117360 IN IP4 0.0.0.0 > s=RTSP Session > c=IN IP4 0.0.0.0 > t=0 0 > a=control:* > a=range:npt=0-10.566000 > m=video 0 RTP/AVP 26 > a=control:rtsp://foo/twister/video > m=audio 0 RTP/AVP 0 > a=control:rtsp://foo/twister/audio > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP/TCP;interleaved=0-1 > > S->C: RTSP/1.0 200 OK > Cseq: 2 > Session: 12345678 > Transport: RTP/AVP/TCP;unicast;client_ip=;interleaved=0-1 > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > CSeq: 3 > Session: 12345678 > > S->C: RTSP/1.0 200 OK > Content-Base: rtsp://foo/twister/ > Cseq: 3 > RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 > Range: npt=0- > Session: 12345678 > > ... now request UDP ... > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 4 > Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 > Range: npt=0- > > S->C: RTSP/1.0 200 OK > CSeq: 4 > Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; > server_port=9000-9001 > RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= > Range: npt=0-10.56600 > Session: 12345678 > > > > > 7. Other transport related changes to RTSP draft > > A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to > transport parameters. > > (a) Section 13.40: > Page 81: Are "src_addr" and "dest_addr" parameters > going away? If these are relevant for NAT, perhaps they belong in > the NAT document? In my opinion they are actually fundamental and belong to the core specification as they represent the basic addressing requirements of allowing for any transport setup. > > Page 83-83: BNF indicates "client_port" and > "server_port" will be indicated as 'port1-port2'. This doesn't seem > adequate for the case where the RTP and RTCP ports are non-adjacent > (per the new RTP spec rfc 3550). > That is what dest_addr and src_addr are created to address as they allow for enumerating any number of address/port constellations in case of IP/port based transport. > Proposal: > client_port: rtp=, rtcp= > server_port: rtp=, rtcp= > Bad Idea from a backwards compatibility stand point. That is why I proposed the dest_addr parameter to take care of this and hopefully any future problems. However I perhaps should be consider to ensure that any type of address can be expressed in this, by doing class, and string definition. > (b) Appendix B, B.1.1 > Page 115: Mentions "src_addresses" and > "dest_addresses" - what are these? > the unshortend versions of "src_addr" and "dest_addr". > Page 116: "non-continuous" ports - might want to rephrase to > "non-adjacent" (or "non-continguous") ports? > Done. > > > 8. Summary > > > This note recommends negotiation of a few transport parameters and > specifies mechanisms to do so. One new transport parameter "client_ip" > is recommended for use in cases where the client's IP address changes > during the session. I also do not understand why you need a new parameter when you have destination or dest_addr to use. > > It is also recommended that the client_port and server_port parameters > be specified further with the use of tags "rtp_port" and "rtcp_port" > to handle the case where these ports are non-contiguous. > As pointed out I don't think changing client_port and server_port is the right way to go. Cheers -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 2 07:20:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13825 for ; Tue, 2 Dec 2003 07:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9Vr-0004Ut-Ag for mmusic-archive@odin.ietf.org; Tue, 02 Dec 2003 07:20:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2CKJFH017283 for mmusic-archive@odin.ietf.org; Tue, 2 Dec 2003 07:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9Vr-0004Ug-6N for mmusic-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 07:20:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13802 for ; Tue, 2 Dec 2003 07:20:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AR9Vp-0005vr-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 07:20:17 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AR9Vo-0005vV-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 07:20:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AR9Vf-0004TR-6o; Tue, 02 Dec 2003 07:20:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQkVd-0005UZ-T6 for mmusic@optimus.ietf.org; Mon, 01 Dec 2003 04:38:25 -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 EAA03021; Mon, 1 Dec 2003 04:38:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQkVZ-0006Cg-00; Mon, 01 Dec 2003 04:38:22 -0500 Received: from mail.zrz.tu-berlin.de ([130.149.4.15]) by ietf-mx with esmtp (Exim 4.12) id 1AQkVZ-0006CV-00; Mon, 01 Dec 2003 04:38:21 -0500 Received: from localhost ([127.0.0.1] helo=mail.zrz.TU-Berlin.DE) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-2) id 1AQkV6-0005Dy-JV; Mon, 01 Dec 2003 10:37:52 +0100 Received: from mail.zrz.TU-Berlin.DE ([130.149.4.15]) by mail.zrz.TU-Berlin.DE (MailMonitor for SMTP v1.2.2 ) ; Mon, 1 Dec 2003 10:37:49 +0100 (CET) Received: from ftmail.ee.tu-berlin.de ([130.149.49.250]) by mail.zrz.tu-berlin.de with esmtp (exim-4.24-2) id 1AQkV2-0003ED-M2; Mon, 01 Dec 2003 10:37:48 +0100 Received: from tkn.tu-berlin.de (ftsu34.tkn.TU-Berlin.DE [130.149.49.204]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id hB19Whn04036; Mon, 1 Dec 2003 10:32:43 +0100 Message-ID: <3FCB0D35.3010907@tkn.tu-berlin.de> Date: Mon, 01 Dec 2003 10:43:17 +0100 From: Heike Klemz User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: klemz@ftmail.ee.tu-berlin.de Content-Type: multipart/alternative; boundary="------------040501020909060200080701" X-Virus-Scanned: Sophos MailMonitor on mail.zrz.tu-berlin.de; Mon, 01 Dec 2003 10:37:49 +0100 Subject: [MMUSIC] CfP: Frist European Workshop on Wireless Sensor Networks 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: , --------------040501020909060200080701 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear Colleague, please notice that the registration deadline for the early registration has been extended to December 7th. Details of the registration, see http://www.ewsn.org Best regards Adam Wolisz Workshop chairman. Technische Universitaet Berlin Fakultaet IV, Institut fuer Telekommunikationssysteme Fachgebiet: Telekommunikationsnetze Einsteinufer 25 10587 Berlin Germany --------------040501020909060200080701 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
Dear Colleague,

please notice that the registration deadline for the early registration 
has been extended to December 7th. Details of the registration, see   http://www.ewsn.org

Best regards

Adam Wolisz
Workshop chairman.
Technische Universitaet Berlin
Fakultaet IV, Institut fuer
Telekommunikationssysteme
Fachgebiet: Telekommunikationsnetze
Einsteinufer 25
10587 Berlin
Germany
--------------040501020909060200080701-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 2 19:01:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25019 for ; Tue, 2 Dec 2003 19:01: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 1ARKS5-0001Hv-SK for mmusic-archive@odin.ietf.org; Tue, 02 Dec 2003 19:01:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30190w004948 for mmusic-archive@odin.ietf.org; Tue, 2 Dec 2003 19:01:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKS5-0001Hg-LQ for mmusic-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 19:01:09 -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 TAA24989 for ; Tue, 2 Dec 2003 19:00:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKS0-00066e-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:01:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARKS0-00066b-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKRy-0001H9-9o; Tue, 02 Dec 2003 19:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKRO-0001Eh-Uk for mmusic@optimus.ietf.org; Tue, 02 Dec 2003 19:00:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24961 for ; Tue, 2 Dec 2003 19:00:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKRK-00065i-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:00:22 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1ARKRI-00063E-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:00:20 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id hB2NxNxC005498 for ; Tue, 2 Dec 2003 15:59:23 -0800 (PST) Received: from jamba (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 <0HPA00AZ9LAZ0U@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 02 Dec 2003 15:59:23 -0800 (PST) Date: Tue, 02 Dec 2003 15:59:58 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] RTSP transport negotiation In-reply-to: <3FCC5294.8040207@ericsson.com> To: Magnus Westerlund Cc: mmusic@ietf.org Message-id: <1070409596.15015.78.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit References: <1066800352.27652.3.camel@jamba> <3FCC5294.8040207@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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Magnus, Thanks for the comments. I should have clarified that this document was mainly intended to address transport negotiation in play state. Your point is well taken, that we do need to specify transport negotiation when a stream is setup too. Also I'm ok with using dest_addr, src_addr, client_port, server_port instead of the new parameters in my document. Rest inline.. On Tue, 2003-12-02 at 00:51, Magnus Westerlund wrote: > Hi Geetha, > > Here is my comments on your write-up. I think one should be clearer on > separating the two cases where one can "negotiate" transport parameters: > 1. Initially when a stream is setup > 2. Changing transport parameters during a session. > > See more inline. I have not removed any of Geetha's mail to make it easy > to read her initial text in full, thus it is a bit long. > > > Geetha Srikantan wrote: > > > Hello everyone, > > > > Here is the promised write-up on RTSP transport negotiation..sorry for > > the delay. If there is agreement on the content of this note, I can > > write up text for the RTSP draft. > > > > thanks > > geetha > > > > > > Topic: RTSP Transport negotiation using SETUP during play state. > > > > Introduction > > > > The RTSP specification allows for negotiation of transport parameters > > via the SETUP method, while the RTSP session is in play state. The > > transport parameters that can be negotiated and the exact form of this > > negotiation is under-specified in the RTSP documents. This note is an > > attempt to clarify some of the issues around transport negotiation for > > inclusion in the ongoing revision of RTSP. > > > > The recent interest in mobility for RTSP implementations also impacts > > transport parameters used by the session. For instance, a wireless > > RTSP client could be assigned a new IP address, or may experience > > change of network characteristics, while it is in the midst of a RTSP > > session. These issues are also addressed in this note. > > > > > > Outline: > > > > 1. Objective > > 2. Enumeration of all Transport Parameters > > 3. Transport Parameters Excluded from Negotiation > > 4. Negotiable Transport Parameters > > 5. Impact of Transport Negotiation > > 6. Examples > > 6.1 Client IP Address Changes > > 6.2 UDP -> TCP > > 6.3 TCP -> UDP > > 7. Other transport related changes to RTSP draft > > 8. Summary > > > > > > > > 1. Objective: > > > > The main goals of this document are to > > * Provide an enumeration of transport parameters. > > * Identify transport parameters that cannot be negotiated > > with minimal impact on other sessions. > > * Propose transport parameters that can be negotiated during > > play state. > > * Determine implications of changing these parameters via a > > SETUP request while the session is in play state. > > * Provide examples demonstrating transport negotiation. > > > > > > 2. Enumeration of all Transport Parameters > > > > The following is a list of all transport parameters in the current > > RTSP draft. > > > > unicast/multicast > > destination > > source > > mode (=PLAY) > > interleaved > > layers (for multicast) > > ttl (for multicast > > port (for multicast) > > client_port (for RTP) > > server_port (for RTP) > > ssrc (for RTP) > > url > > > > You are missing a few and "url" is not a parameter. > dest_addr > src_addr > append > Transport protocol and Profile > Lower layer transport > Right..will add those. > > > > 3. Transport Parameters Excluded from Negotiation > > > > It is recommended that the following parameters be excluded from the > > negotiation process. > > > > mode > > url > > unicast/multicast > > layers > > ttl > > ssrc > > destination > > source > > > > > > As the "mode" parameter is restricted to a single value in the > > current draft, it can be excluded. > > I think that this is a very fundamental parameter if also record is add > again in the future. > I agree that mode is an important parameter, however I am wondering if it would be reasonable to change from say mode=play to mode=record during play state? I guess this would enable Tivo-like functionality on a playing session, is that what you had in mind? If that's the case, this switch in parameter should be allowed. > > > > As per the recent proposal to not support addition of urls via SETUP > > during play state, the "url" parameter can be excluded. > > I think the Request URL are somewhat out of scope for this discussion, > as it actually provides the scope for the negotiation. The Request URL > will indicate for the server if the client desires to do: > > 1. Setup up a new stream (only possible in "init" or "ready" state) > 2. Change the transport parameters for a stream. > > However in both cases the transport parameters can be "negotiated" so > this applies for both of them. I just thinks that one must be clear > about the different scopes. However in both cases one must include all > the parameters one likes to have applied. > Right, will include that in the next revision. > > > > Changing from multicast to unicast based on a single RTSP session's > > SETUP, would impact all the other clients accessing the multicast > > session. > > Several issues need to be considered in this case, including transport > > negotiation. Similarly, changing from unicast to multicast also has > > implications beyond a single RTSP session. Changes to other > > multicast-related parameters, "layers", "ssrc", "ttl" most likely > > requires specification beyond transport negotiation. > > The recommendation is to *not* specify changing the transport from > > "unicast" to "multicast" or vice versa, and also not specify changes > > to the "layers" and "ttl" parameters, in this draft. It is recommedned > > that negotiation of multicast-related transport parameters should be > > deferred to an RTSP-extension document. > > > > Once an RTSP session has been initiated and the "destination" and > > "source" have been established - i.e. a multicast "destination" has > > been identified, and the stream "source" has been identified, there > > should be no need to change these parameters. It is recommended that > > the "destination" and "source" parameters not be negotiated when the > > session is in play state. The case of the client IP address change is > > signaled in a different manner, outlined in the next section. > > > > I think that SSRC can if not negotiated, at least be changed by the > server if deemed necessary, however this is probably not recommended. > I'll add a note about this. > Transport protocol and profile does seem to belong to this class of > parameters that are established initially but then not intended to be > changed during a session. > I agree the transport protocol and profile should not be allowed to change. > > > > 4. Negotiable Transport Parameters > > > > Hence there are three main conditions that require transport > > negotiation for unicast: > > > > * client IP address changes > > * client wants to switch transport from UDP -> TCP > > * client wants to switch transport from TCP -> UDP > > > > Changes in the client IP address can be indicated using a new > > "client_ip" parameter. Hence the parameters that are impacted by > > transport negotiation are: > > > > client_ip > > interleaved > > client_port > > server_port > > > > I think we should clarify client ip and port with destination > address/port. I also think an important parameter to discuss in this > context is the lower layer transport. I would think that the transport > protocol and profile are not likely to change. > So we do not allow changing: transport protocol and profile. We allow changing: client ip and port lower layer transport server port Server port may change only as a result of client address/port change. Since the RTP/RTCP client and server endpoints need to be unique. > > > > 5. Impact of Transport Negotiation > > > > The first column describes the primary change, the second and third > > columns describe any secondary transport parameters that MUST or > > MAY change as a result of the primary change. > > > > > > Changed MUST MAY > > ------- ---- --- > > > > Client IP address client_ip client_port > > server_port > > > > UDP -> TCP interleaved Server may change > > Drop client_port interleaved channel ids > > Drop server_port in response. > > > > TCP -> UDP client_port in request client_ip > > server_port in response client_port in response > > Drop interleaved > > > > > > I think one should clarify that in TCP->UDP changes one must now include > (add) a destination port in the request. > Will add that. > > > > 6. Examples > > > > 6.1 Client IP Address Changes > > > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 > > CSeq: 1 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 1 > > Content-Type: application/sdp > > Content-Length: 164 > > > > v=0 > > o=- 2890844256 2890842807 IN IP4 172.16.2.93 > > s=RTSP Session > > i=An Example of RTSP Session Usage > > a=control:rtsp://foo/twister > > t=0 0 > > m=audio 0 RTP/AVP 0 > > a=control:rtsp://foo/twister/audio > > m=video 0 RTP/AVP 26 > > a=control:rtsp://foo/twister/video > > > > There shall be a "c=" line somewhere. Then a question, how does the > client learn that if this session is multicast that it really is? Is > that totally dependent on that the "c=" address is of multicast type? > Yes, the c= line is missing..thanks for pointing it out. That's usually how the client determines if it's a multicast - by looking at the address type in the c= line. > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP;unicast;client_port=8000-8001 > > If one would like to have a good example of initial "negotiation" then > the client should include multiple transport specs for the server to > choose from. > That seems reasonable. What would be the preferred format for that. Some thing like this: C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001, RTP/AVP/TCP;interleaved=0-1 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 2 > > Transport: RTP/AVP;unicast;client_port=8000-8001; > > server_port=9000-9001 > > Session: 12345678 > > In the setup response the server should include a "ssrc" parameter to > indicate what SSRC it will use and for which the RTP-Info is valid. > Right..I missed that earlier..will include it. > > > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 3 > > Transport: RTP/AVP;unicast;client_port=8002-8003 > > Session: 12345678 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 3 > > Transport: RTP/AVP;unicast;client_port=8002-8003; > > server_port=9004-9005 > > Session: 12345678 > > > > SSRC again. > > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 4 > > Range: npt=0- > > Session: 12345678 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 4 > > Session: 12345678 > > RTP-Info: url=rtsp://foo/twister/video; > > seq=9810092;rtptime=3450012, > > url=rtsp://foo/twister/audio;seq=5923;rtptime=22234432 > > Range: npt=0-30.76 > > > > ... now change client IP address .... > > > > C->S: SETUP rtsp://foo/twister/video RTSP/1.0 > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip= > client_port=8002-8003;server_port=9004-9005 > > Range: npt=5- > > Session: 12345678 > > > > The parameter is not "client_ip" it is either "destination" or "dest_addr". > I'm ok with using dest_addr. I was not sure if it's ok to re-use dest_addr, that's why I introduced client_ip (and client_port later). > As discussed previously the use of Range in the Request makes little sense. Right this will be taken out. > > > S->C: RTSP/1.0 200 OK > > CSeq: 5 > > Transport: RTP/AVP;unicast;client_ip=; > > client_port=8002-8003;server_port=9004-9005 > > RTP-Info: url=rtsp://foo/twister/video; > > seq=;rtptime=, > > Range: npt=5-30.76 > > Session: 12345678 > > > > I also think one should point out why one includes Range here. In > regards to the RTP-Info, I think that one should primarily indicate the > RTP sequence number in RTP-Info. Using rtptime combined with "Range" > might not be the best, because one would normally not intend to change > anything in the npt <-> RTP TS binding, as it would cause real problems > for a client during playback. > I think the concern is that the client may need to re-sync after transport negotiation. I didn't mean to imply that there would be a change in the NPT <-> timestamp correspondence. Including seq and rtptime in RTP-Info would make it easier for the client. I can rephrase it to say that the server should not change the NPT <=> timestamp correspondence during transport negotiation. > > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 6 > > Transport:RTP/AVP;unicast;client_ip=; > > client_port=8000-8001;server_port=9000-9001 > > Range: npt=5- > > Session: 12345678 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 6 > > Transport: RTP/AVP;unicast;client_ip=; > > client_port=8000-8001;server_port=9000-9001 > > RTP-Info:url=rtsp://foo/twister/audio; > > seq=;rtptime= > > Range: npt=5-30.76 > > Session: 12345678 > > > > > > > > > > 6.2 UDP -> TCP > > > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > > CSeq: 1 > > > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Content-Length: 230 > > Content-Type: application/sdp > > Cseq: 1 > > > > v=0 > > o=- 3262117360 3262117360 IN IP4 0.0.0.0 > > s=RTSP Session > > c=IN IP4 0.0.0.0 > > t=0 0 > > a=control:* > > a=range:npt=0-10.566000 > > m=video 0 RTP/AVP 26 > > a=control:rtsp://foo/twister/video > > m=audio 0 RTP/AVP 0 > > a=control:rtsp://foo/twister/audio > > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 > > > > S->C: RTSP/1.0 200 OK > > CSeq: 2 > > Session: 12345678 > > Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; > > server_port=9000-9001 > > > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 3 > > Session: 12345678 > > > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > CSeq: 3 > > RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 > > Range: npt=0- > > Session: 12345678 > > > > ... now request TCP ... > > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 4 > > Transport: RTP/AVP/TCP;interleaved=0-1 > > > > S->C: RTSP/1.0 200 OK > > Cseq: 4 > > Transport: RTP/AVP/TCP;unicast; > > client_ip=;interleaved=0-1 > > RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= > > Range: npt=0-10.56600 > > Session: 12345678 > > > > > > > > 6.3 TCP -> UDP > > > > C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.0 > > CSeq: 1 > > > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Content-Length: 230 > > Content-Type: application/sdp > > Cseq: 1 > > > > v=0 > > o=- 3262117360 3262117360 IN IP4 0.0.0.0 > > s=RTSP Session > > c=IN IP4 0.0.0.0 > > t=0 0 > > a=control:* > > a=range:npt=0-10.566000 > > m=video 0 RTP/AVP 26 > > a=control:rtsp://foo/twister/video > > m=audio 0 RTP/AVP 0 > > a=control:rtsp://foo/twister/audio > > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 2 > > Transport: RTP/AVP/TCP;interleaved=0-1 > > > > S->C: RTSP/1.0 200 OK > > Cseq: 2 > > Session: 12345678 > > Transport: RTP/AVP/TCP;unicast;client_ip=;interleaved=0-1 > > > > C->S: PLAY rtsp://foo/twister RTSP/1.0 > > CSeq: 3 > > Session: 12345678 > > > > S->C: RTSP/1.0 200 OK > > Content-Base: rtsp://foo/twister/ > > Cseq: 3 > > RTP-Info: url=rtsp://foo/twister/audio;seq=7028;rtptime=1339949552 > > Range: npt=0- > > Session: 12345678 > > > > ... now request UDP ... > > > > > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > > CSeq: 4 > > Transport: RTP/AVP/UDP;unicast;client_port=8000-8001 > > Range: npt=0- > > > > S->C: RTSP/1.0 200 OK > > CSeq: 4 > > Transport: RTP/ACP/UDP;unicast;client_port=8000-8001; > > server_port=9000-9001 > > RTP-Info: url=rtsp://foo/twister/audio;seq=;rtptime= > > Range: npt=0-10.56600 > > Session: 12345678 > > > > > > > > > > 7. Other transport related changes to RTSP draft > > > > A few comments on draft-ietf-mmusic-rfc2326bis-04.txt relating to > > transport parameters. > > > > (a) Section 13.40: > > Page 81: Are "src_addr" and "dest_addr" parameters > > going away? If these are relevant for NAT, perhaps they belong in > > the NAT document? > > In my opinion they are actually fundamental and belong to the core > specification as they represent the basic addressing requirements of > allowing for any transport setup. > Sounds good? > > > > Page 83-83: BNF indicates "client_port" and > > "server_port" will be indicated as 'port1-port2'. This doesn't seem > > adequate for the case where the RTP and RTCP ports are non-adjacent > > (per the new RTP spec rfc 3550). > > > > That is what dest_addr and src_addr are created to address as they allow > for enumerating any number of address/port constellations in case of > IP/port based transport. > Would you please give an example of what this looks like for non-adjacent RTP and RTCP ports for a stream? Since RFC 3550 allows non-adjacent ports, the BNF in the current draft would mean this is written as: C->S SETUP rtsp://example.com/foo/bar/bar.rm RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=4588-6129 if the RTP port is 4588 and RTCP port is 6129. This should not be interpreted as a port range by the server. That's the problem I was referring to. > > Proposal: > > client_port: rtp=, rtcp= > > server_port: rtp=, rtcp= > > > > Bad Idea from a backwards compatibility stand point. That is why I > proposed the dest_addr parameter to take care of this and hopefully any > future problems. However I perhaps should be consider to ensure that any > type of address can be expressed in this, by doing class, and string > definition. > If the client_port and server_port is rephrased to have non-adjacent ports, then there is no need for the change I suggest. > > (b) Appendix B, B.1.1 > > Page 115: Mentions "src_addresses" and > > "dest_addresses" - what are these? > > > > the unshortend versions of "src_addr" and "dest_addr". > > > Page 116: "non-continuous" ports - might want to rephrase to > > "non-adjacent" (or "non-continguous") ports? > > > > Done. > > > > > > > 8. Summary > > > > > > This note recommends negotiation of a few transport parameters and > > specifies mechanisms to do so. One new transport parameter "client_ip" > > is recommended for use in cases where the client's IP address changes > > during the session. > > I also do not understand why you need a new parameter when you have > destination or dest_addr to use. > see earlier comment.. > > > > It is also recommended that the client_port and server_port parameters > > be specified further with the use of tags "rtp_port" and "rtcp_port" > > to handle the case where these ports are non-contiguous. > > > > As pointed out I don't think changing client_port and server_port is the > right way to go. > > see earlier comment.. > > > Cheers thanks geetha -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 2 19:17:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25341 for ; Tue, 2 Dec 2003 19:17:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKhT-0001uG-6j for mmusic-archive@odin.ietf.org; Tue, 02 Dec 2003 19:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30H3IC007322 for mmusic-archive@odin.ietf.org; Tue, 2 Dec 2003 19:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKhS-0001u1-OK for mmusic-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 19:17: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 TAA25324 for ; Tue, 2 Dec 2003 19:16:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKhQ-0006HK-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:17:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARKhQ-0006HE-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKhQ-0001tJ-PT; Tue, 02 Dec 2003 19:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKh4-0001sk-FG for mmusic@optimus.ietf.org; Tue, 02 Dec 2003 19:16:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25286 for ; Tue, 2 Dec 2003 19:16:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKh2-0006GE-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:16:36 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1ARKh1-0006ES-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:16:35 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hB30G5UP013694 for ; Tue, 2 Dec 2003 16:16:05 -0800 (PST) Received: from jamba (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 <0HPA00J9FM2T48@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Tue, 02 Dec 2003 16:16:05 -0800 (PST) Date: Tue, 02 Dec 2003 16:16:41 -0800 From: Geetha Srikantan To: mmusic@ietf.org Message-id: <1070410598.15015.97.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Proposal for Streaming Relays - RTSP additions Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, As discussed at the MMUSIC meeting in Minneapolis, we would like to outline usage scenarios for certain RTSP methods. We'd like to propose a few RTSP additions to support n-tier streaming relays. Enclosed is a proposal on the topic. thanks geetha Streaming Relays Date: 12/2/2003 Geetha Srikantan John Murata Andrew Large 1.0 Abstract Delivery of streaming media to a large number of clients distributed across several geographic and network boundaries presents several challenges in terms of scalability and stream quality. This document describes N-tier relays to address scalability and quality issues in the delivery of stored and live content. This document addresses issues in stream synchronization, content announcement/expiry, reliability of transport, failover/recovery, administration, and security issues. This document propose a set of primitives to enable implementation of Push and Pull mechanisms for N-tier relays. We also provide usage scenarios where each approach is most useful. The Pull and Push mechanisms are complementary and provide valuable building blocks in N-tier relays. This document introduces a few new RTSP methods and headers. 2.0 Terminology * Source - A source of media streams - either live or stored content may be used. The Source implements RTP and RTCP and produces RTP and RTCP packets for each media stream. The Source may or may not implement RTSP. * Live Source - A Source for live streams. It does not support RTSP 'PAUSE' and media streams are only available at the restricted times when the live session is in progress. * Broadcast - In the sense of a FM radio broadcast. The content could be either live or stored. Streams of RTP and RTCP packets are available with some degree of synchronization information. The streams can be sent over unicast or multicast. * Broadcaster - A network element which is a Source with Broadcast capability. * Server - An RTSP server implementation. Also an RTP and RTCP server implementation. * Client - An RTSP client implementation. Also an RTP and RTCP client implementation. * Player - A Client which renders media streams to end-user. * N-tier Relay - A network or group of networks with multiple tiers of hosts or network elements, each of which may be a Source, Live Source, Broadcaster, Server or Client. The Source, Live Source or Broadcaster is at the top tier of the relay. Several tiers of servers may exist. The last tier of the relay is the edge tier of nodes that stream content to Players. * Relay Node - A network element in any tier, except the last tier of an N-tier relay; i.e. any non-Player node. * Edge Node - A network element that is at the edge of the n-tier relay, and serves Players. * Interior Node - A network element that is at any tier, preceding the Edge tier of the relay; i.e. any Relay Node which is not an Edge Node. * Pull - The capability to pull content to into a network element. * Push - The capability to push content to a network element. * Publish - The capability to notify a network element about the availability of content or streaming session. 3.0 Introduction Delivery of streaming media to a large number of clients distributed across several geographic and network boundaries presents several challenges. Scalability and stream quality issues are addressed by using multiple relay nodes in the network, all of which deliver the same streaming session to clients. The nature and topology of such N-tier relays vary widely and interoperability will benefit from a clarification of behavior for relays and negotiated broadcasts for both TCP and UDP. This document outlines the main issues in relay networks and proposes primitives to enable n-tier relays. These primitives are based on RTSP, SDP, RTP/RTCP. Two kinds of relay modes are introduced, (a) Reflection, where packets are forwarded by relay nodes, without any alteration, and (b) Translation, where packet headers may be modified by intermediate relay nodes. Automated publication of SDP for live sessions using the RTSP ANNOUNCE method is also presented. The next section outlines main issues to consider in live streaming and N-tier relays. The following section describes motivation, details, assumptions and implications for each mechanism of the proposed solution. Use cases for these mechanisms are also provided in this section. The final section summarizes the N-tier relay approaches proposed in this document. It highlights the usage of old and new RTSP methods and headers in relays and also makes recommendations about including these either in the core RTSP spec or in an extension document. 4.0 Problem Scope This section describes the main issues in: * live streaming, and, * N-tier relays and broadcasts. 4.1 Live Streaming Problem Statement Live streaming includes a live source and one or more streaming servers that deliver the live stream to several downstream clients. Live streaming can also happen directly from a broadcaster as in the case of multicast broadcast. In order for live streaming to work, the SDP file describing a live session is published at the streaming server's content root typically using one of the following mechanisms: - manually ftp'ing the SDP file from the live source host to the streaming server host (onto the content root of the streaming server); - via a webserver; - via email, etc. At this point the live session can be accessed from the streaming server via the SDP file. Scalability and stream quality issues are addressed by using multiple relay nodes in the network, all of which deliver the same live session to clients. Examples of relays: 1. Server can pull a broadcast from another server with RTSP DESCRIBE/SETUP/PLAY methods and then relay or re-broadcast the streams or make the streams available to clients as a server. 2. Server can receive a push broadcast from a broadcaster that uses RTSP ANNOUNCE/SETUP/RECORD and then either relay or serve the broadcast. 3. There are situations, as in the case of an SDP declared UDP unicast or multicast broadcast, where there is an ANNOUNCE with no SETUP and no RECORD from the broadcaster. This arises in cases wherer (a) the broadcaster is not a complete RTSP-server implementation, and/or (b) when the multicast session is in progress and it is not possible to accurately determine the interaction points of RTSP and RTP/RTCP. When relay nodes deliver the live stream, network delays and the asynchronous nature of live streaming can result in synchronization issues at the streaming server and clients. There are different synchronization issues: - Minimum or controlled time lag from the original broadcast, so all watching or listening clients are viewing the same point in the broadcast regardless of how many relay nodes are between each Player instance and the Source. - If controlled lags or delays are allowed, at which point should they be introduced for each stream - which tier of the relay; which nodes? - Stream synchronization between streams of the same broadcast - is not easy when a client must tune into a live multicast broadcast. Two important security concerns around live streaming are: (a) A relay node may need to determine whether the live source that is announcing content, is a legitimate live source. (b) The live source may need to know if a relay node requesting content is a legitimate client. >From the above it is clear that an integrated solution for live streaming should address automated publication of live content, scalability concerns, quality and synchronization issues, and security concerns. 4.2 N-tier Relay and Broadcast Issues Section 4.1 outlined the main issues in live streaming. Many of the issues that are pertinent to live relays also apply to relays of stored content. This section outlines issues in enabling both broadcasts and relays of live and stored content. * Content Announcement and Expiry. Stored content may be deployed by a content management system at many nodes; the nodes need to be made aware of the availability of new stored content. Live source needs to inform relay nodes about the availability of a new live streaming session so that the relay node can access the session content in preparation for delivery to its clients. Media descriptions about a new streaming session can include the SDP that would normally be sent in a RTSP DESCRIBE response as well as expiry information, and other meta-information regarding this content. Media announcements can be made to indicate the availability of new sessions or to revoke a previous announcement. Players or other clients requesting an expired or revoked session should be sent a suitable message indicating that this content is no longer available. * Synchronization of streams within a session. As noted earlier, network delays and other factors can cause arbtrary delays in the delivery of media streams at all relay nodes. A session with a single media stream can use the arrival time of a RTP packet maps to NPT 0 (NPT == Normal Play Time), and record the packet's sequence number and timestamp to correspond with NPT 0. When more packets arrive it can determine whether these are older or newer packets and decide to discard or use these packets. When multiple streams form a session, there is usually a need to synchronize playout of these streams. Synchronization requires correspondence of the NPT clock to each media stream. Typically RTSP PLAY responses will contain a Range header with NPT info and a RTP-Info header with url, sequence number and timestamp of RTP packets that correspond to the NPT in the Range header. This information is sufficient for synchronization of streams. In cases where the relay is forwarding multicast, information for RTSP headers such as RTP-Info, is not available. As a result the synchronization requirements are necessarily weaker, in such scenarios. * Reliability of transport. When the N-tier relay spans several networks, arbitrary delays and losses in transmission are possible. Use of TCP for data transport is recommended to avoid losses and packet-reordering that UDP may introduce. * Firewalls Firewalls between any two nodes in the N-tier relay complicate matters. The simplest approach is to use TCP transport across firewalls. * Failover and Recovery of the Relay. If the broadcaster crashes and needs to be restarted, a relay recovery mechanism is needed. This could be based on (a) IP failover at the broadcaster, so relay nodes can auto-reconnect. (b) Via an explicit ANNOUNCE from the broadcaster after it has recovered. (c) From a backup broadcaster instance, etc. In case a relay node stops receiving streaming content unexpectedly, it can recover the streams by either by retrying connection to the upstream node, or by awaiting explicit notifcation of a new upstream source. If the relay node initiates retries, the rate of frequency and duration of retries may be signalled or configured. An abrupt end of the session may need to be signalled to relay nodes, as well. In case the broadcaster wants to disconnect and rebroadcast with a different set of addresses or different set of encodings, it will need to notify all its recipients of this change. * Security. There is a need to disallow arbitrary media announcements from unauthorized sources to relay nodes. Relay nodes such as live sources or broadcasters may need to authenticate requests for relay content. Protection of media distribution rights in an N-tier relay is desirable in many usage scenarios. * Administration. Each interior node in the relay needs to be configured with valid upstream and downstream hosts. Each edge node in the relay needs to be configured with valid upstream hosts. 5.0 Proposed Solution We propose a set of primitives that will enable n-tier relays and broadcasts for both live and stored content. In this approach the client and server interactions are such that a relay node can be both a relay/server and a broadcaster. The main components of the proposed solution are: * Two relay modes - Reflection and Translation. * Two relay mechanisms - Push and Pull. * Automated publication of live/stored content. The following subsections will discuss each of these components in detail. For each we provide (a) details, (b) assumptions, (c) implications, (d) pros/cons, (e) any new protocol primitives needed. 5.1 Relay Modes Two relay modes are described here - Reflection and Translation. 5.1.1 Reflection The source or broadcaster is typically RTP/RTCP implementations and either partial or complete RTSP implemetations. Media packets are forwarded without any modifications. Nodes in such relays may not have access to RTSP-specific information such as the mapping between NPT and timestamps of each stream in an RTSP session, consequently the stream-synchronization requirements are weaker in this relay mode. In case the broadcast stops or there is a failure in reception of content at the node, the relay node can send an end-of-stream notification to all its clients so they can teardown their sessions. 5.1.1.1 Reflection - Pros * Simple and easy to deploy. 5.1.1.2 Reflection - Cons * Lack of synchronization between streams can get amplified, particularly at tiers of the relay that are further away from the Source. 5.1.2 Translation The source or broadcaster is an RTSP server implementation. All the interior components of the relay implement RTSP and RTP/RTCP. In this mode, RTP timestamps (and sequence numbers) on packets may be translated to assist in stream synchronization and quality . In the event of a broadcaster/source failure, the interior relay nodes may provide sophisticated failover and recovry mechanisms. 5.1.2.1 Translation - Pros * Synchronization issues are addressed explicitly (except in multicast). 5.1.2.2 Translation - Cons * Complexity and extra processing at each node can add to latency. * Broadcaster needs to be a RTSP server implementation. * Broadcaster and relay/server need a mechanism to signal stream synchronization metadata. 5.2 Relay Mechanisms Two complementary relay mechanisms are presented here. In the Pull mechanism downstream relay nodes, such as streaming servers initiate the delivery of streams from upstream nodes. In the Push mechanism upstream nodes send content to downstream relay nodes. 5.2.1 Pull - Streaming Server Driven Approach In this approach, interior relay nodes such as a streaming server pull content from the broadcaster/source. The broadcaster sends ANNOUNCE with SDP contents and headers indicating expiry/lifetime and delivery protocol for the content. This causes the streaming server to request content from the source via SETUP, PLAY - as an RTSP client. The broadcaster behaves like a streaming server and the downstream server behaves like a streaming client. That is, the interactions are as follows at the first tier of the relay: Broadcaster -> Relay Node ANNOUNCE SDP file with expiry info Relay Node -> Broadcaster Acknowledge ANNOUNCE Relay Node -> Broadcaster SETUP request to setup a stream from SDP Broadcaster -> Relay Node SETUP response Repeat the above two steps as many times as needed for the session. Relay Node -> Broadcaster PLAY request for the session Broadcaster -> Relay Node PLAY response w/ Range header, RTP-Info In other tiers of the relay, the upstream relay node plays the role of the Broadcaster. The broadcaster provides stream synchronization information in the PLAY response to the relay node requesting the content (except in the case of multicast). From this point on, each relay node can maintain its own NPT clock and a correspondence tuple of for each stream in the session. This will permit the node to convey this information to any of its recipients. In case the broadcast or source fails, the server will retry connecting to the source, every so often, until it receives notifcation that the SDP has been revoked or has expired. That is, the relay node is responsible for restart. Configurable timeouts for retry attempts may also be used. 5.2.1.1 Pull - Pros - Explicit correspondence, when this information is available from the source. - Streaming servers can request content from source as and when they need to (when there are downstream clients requesting this). 5.2.1.2 Pull - Cons - Authentication and authorization needs to be handled at source (so it can validate requests for content, and so it can validate itself when publishing content). The relay/server needs to validate itself at source before it can request for content (and validate downstream clients, as usual). - Source is now a RTSP server. - Extra administration, security and system complexity. 5.2.2 Push - Source Driven Approach In the Push approach the source or broadcaster initiates delivery of the streaming session to the relay/server. The source sends ANNOUNCE with SDP and expiry/delivery info. Next, the source sends SETUP with mode=receive and RECEIVE to the server. Another way to support this would be for the source to send SETUP_RECEIVE to the relay node, followed by RECEIVE. The interactions at the first tier of the relay are as follows: Broadcaster -> Relay Node ANNOUNCE SDP file with expiry info Relay Node -> Broadcaster Acknowledge ANNOUNCE Broadcaster -> Relay Node OPTIONS request to determine server push capability Relay Node -> Broadcaster OPTIONS response with 'RECEIVE' implies push capable. Broadcaster -> Relay Node SETUP_RECEIVE Relay Node -> Broadcaster SETUP_RECEIVE response with server-side port numbers. Repeat these two steps as many times as needed. Broadcaster -> Relay Node RECEIVE request w/ Range header and RTP-Info, if available. Relay Node -> Broadcaster RECEIVE response The relay node now has access to the streams and can deliver them to its recipients. If relay node receives streams over unicast UDP, it can select ports and return them in the SETUP or SETUP_RECEIVE response. The RECEIVE request contains Range nor RTP-Info headers, if available. The RECEIVE response will contain RTP-Info header with urls only (no sequence number or timestamp). If multicast UDP transport is used to send media to the relay node then the source/broadcaster determines the ports to be used. Also the RECEIVE request may contain a Range header, however the RECEIVE response will contain neither Range not RTP-Info headers. If the source provided Range and RTP-Info headers with synchronization information, then the relay node maintains an implicit correspondence between the NPT (from Range header) to the RTP sequence number and timestamps. 5.2.2.1 Push - Pros - All security issues are handled by the streaming server - it can validate the source, just as it validates clients. - Source/Broadcaster need not be a complete RTSP implementation. 5.2.2.2 Push - Cons - A relay node will have to receive the streams from the source, regardless of whether downstream clients ask for them or not. - No mechanism for relay node to request content after the ANNOUNCE. Relay node is forced to accept streams from the source or miss the session entirely. 5.2.2.3 New Primitives * A new RTSP method 'RECEIVE' is introduced, the sender of a RECEIVE request intends to send media to the recipient of the request. The receiver of this request can indicate whether it is ready to receive such streams in the RECEIVE response. * The RTSP method SETUP, if used with 'mode=receive' parameter, would be used in establishing transport for a new stream. The sender of a SETUP request with mode=receive attempts to establish the transport by providing its own transport parameters. The receiver of this request responds with its transport parameters, if it supports this mode. The sender of this request intends to use the transport for a subsequent RECEIVE request, by which it will send media streams to the recipient. Using the SETUP method with mode=receive will require only one additional RTSP parameter 'mode=receive' to be defined. This is similar to the usage of SETUP/RECORD in RFC 2326. OR A new RTSP method SETUP_RECEIVE, with the same headers as SETUP can be used instead. If this method is introduced, then SETUP would be used by a client requesting media from a server, and SETUP_RECEIVE would be used by a source/server intending to send media to a client. Using this method introduces a brand new method into RTSP. 5.3 Automated Publication of Live/Stored Content In both the Pull and Push mechanisms, the RTSP ANNOUNCE method signals availability of content. The SDP in the ANNOUNCE can use port number 0 to indicate that the relay node can pick a port number for this media. ANNOUNCE request can also contain headers to indicate the expiry of this content, with the inclusion of additional RTSP x- headers. Etags may also be used to indicate expiry. ANNOUNCE requests may be sent to relay nodes to revoke a previously announced SDP, as well. Typical use cases of using ANNOUNCE are: An ANNOUNCE client, such as a source/broadcaster sends ANNOUNCE. An ANNOUNCE server receives ANNOUNCE requests. An ANNOUNCE client and server implementation is recommended at relay/server nodes. 5.3.1 Automated Publication - Pros * When SDP is announced via RTSP ANNOUNCE , there is no need for external entity like a webserver or mail server for publishing the content. In cases where the SDP file is out-of-date, a new ANNOUNCE from the live source to the server will bring the SDP up-to-date. 5.3.2 Automated Publication - Cons * An additional RTSP method needs to be supported on clients and servers. 5.3.3 New Primitives The RTSP ANNOUNCE method described in RFC 2326 can be restored. Two new methods ANNOUNCE_RECEIVE and ANNOUNCE_RELAY can be used to indicate capability as well. * The RTSP method ANNOUNCE could be used to announce content available for multicast and also signal multicast push capability of the recipient, in the ANNOUNCE response. * A new RTSP method ANNOUNCE_RELAY could be used to announce content that is accessible via unicast pull mechanism in the relay. The recipient of a ANNOUNCE_RELAY can respond with its capability to handle unicast pull. * A new RTSP method ANNOUNCE_RECEIVE could be used to announce content that is accessible via unicast push mechanism in the relay. The recipient of a ANNOUNCE_RECEIVE can respond with its capability to handle unicast push. * New RTSP headers: "x-content-expire: " can be used to indicate the lifetime of the SDP being ANNOUNCE'd. "x-relay-recovery: " can be used to indicate the preferred relay recovery mechanism for this SDP. "x-revoke-content: true" can be used to indicate that the SDP being ANNOUNCE'd is no longer available to recipients. 5.4 N-tier Relay and Broadcast Issues 5.4.1 Synchronization Issues To address synchronization issues: (a) SDP t= line should be accurate about duration and actual time of a live session. Extra RTSP x- headers to indicate meta info about the SDP file would be good - for example, expiry of SDP. (b) PLAY response SHOULD contain Range header with an numeric time value, such as Range: npt:0- and not Range: now- (c) PLAY response SHOULD contain RTP-Info header - the timestamp is required for synchronization. The sequence number field is not essential - in fact for multicast/UDP case the client's use of the sequence should be relaxed to expect any packets with sequence numbers greater than or equal to that mentioned in the RTP-Info header (modulo rollover of the sequence number space). 5.4.2 Reliability In general it is better, if possible, to broadcast/relay over TCP using announced interleaved streams so you have a reliable broadcast until you get to an edge server. This is better than UDP streams in an uncontrolled network environment because UDP packet loss in a broadcast stream will be reproduced for all downstream clients. We also assume that using TCP transport will resolve firewall issues. 5.4.3 Failover and Recovery RTSP x- headers can be used to indicate desired behavior in case the broadcast or live source fails. Whether to disconnect and/or retry, maintain SDP reference to the streams etc. These headers should be included in the ANNOUNCE request that is used to indicate availability of the session. When clients request SDP that is no longer valid they will receive a RTSP 404 (Not Found) or 401 (Unauthorized). 5.4.4 Teardown Teardown - could be based on reference counting particularly in the multicast case. 5.5 Discussion of Pull and Push mechanisms 5.5.1 Push Implications The Push mechanism implies that the broadcaster/source need not be a full RTSP server implementation. However the first tier from the source should be an RTSP-server implementation - SETUP with mode=receive or SETUP_RECEIVE, along with RECEIVE; other interior nodes of the network may or may not be required to use the push scenario. The topology can support both push and pull scenarios at other tiers of the network. A Push-based relay will use the Reflection mode and not the Translation mode of operation (i.e. the SSRC generated by the origin will be retained throughout the network). 5.5.2 Pull Implications The Pull mechanism implies that the broadcaster/source has to be a full RTSP server implementation. The interior nodes (except the source) need to be RTSP clients and servers and do not need to support SETUP with mode=receive or SETUP_RECEIVE, nor RECEIVE methods. In a Pull-based relay a server (interior node) may retry connections to the origin until the SDP is revoked via an ANNOUNCE, say. In a Pull-based relay, when relay content is no longer available, the relay/server should send ANNOUNCE for all its configured relays and a End-of-stream notification to all of its recipients. The ANNOUNCE request should carry additional headers to indicate preferred relay behavior in the event that the origin server dies. In Pull-based relay nodes, the relay node reinitiates contact with upstream node for streams. In Push-based relay nodes, the relay nodes give the upstream a chance to recover before timing out the sessions. Pull-based relays allow alternate upstream relays. In case the source/upstream node dies, a single retry attempt is made to the source/upstream node, if that fails, the node can connect to an alternate upstream relay. The clients will see an effective PAUSE; i.e. timestamps will skip over the duration of the failover, and sequence numbers will increment by 1, as in case of a PAUSE. Can have NTP-like stratum failover. 5.5.3 Translation in Pull and Push Mechanisms. Translation is only possible with the following semantics in either the Pull or Push mechanisms: C-S SETUP PLAY S->C PLAY response Range: npt:x-y (x is a number, not 'now') RTP-Info OR C->S SETUP_RECEIVE RECEIVE Range: npt:x-y (x is a number, not 'now') RTP-Info In both cases, the Range header must contain a numeric start of range and not 'now', and the RTP-Info header must contain RTP timestamps and urls for each stream. 5.5.4 Interactions between Relay Pull and Push Clients and Servers A Relay Push Client talks to a Relay Push Server, by sending it SETUP w/ mode=receive or SETUP_RECEIVE request, followed by a RECEIVE request, and sends RTP/RTCP data to the Relay Push Server. A Relay Push Server would handle short periods of outage from the origin, and perform no translation of RTP packets and no failover of the Relay Push Client. A Relay Pull Client talks to a Relay Pull Server by sending it a SETUP request/s with mode=play and a PLAY request, and receives RTP/RTCP data from the Relay Pull Server. A Relay Pull Client would translate/transform RTP timestamps and sequence numbers and may use an alternate upstream relay node. A Relay Pull Client needs to be a ANNOUNCE server, if it supports ANNOUNCE methods. If there is a live broadcaster then the broadcaster is a Relay Pull Client or Relay Push Client in either case it is also a ANNOUNCE client, if it supports the ANNOUNCE methods. A relay node that is not a source node, edge node or player is: * an ANNOUNCE client+server if it supports the ANNOUNCE methods, and * one or both of (a) Relay Push Client & Server or (b) Relay Pull Client & Server. 5.5.5 Capability Determination The functionality supported by each interior relay node, which is typically a server can be indicated as follows in an RTSP OPTIONS response. Basic Server => DESCRIBE, SETUP, PLAY Multicast Push Server => ANNOUNCE, DESCRIBE, SETUP, PLAY Unicast Pull Server => ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY Unicast Push Server => ANNOUNCE_RECEIVE, DESCRIBE,SETUP, PLAY, RECEIVE Unicast Push & Pull Server => ANNOUNCE_RECEIVE, ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY, RECEIVE Multicast Push, Unicast Push, Unicasll Pull Server => ANNOUNCE, ANNOUNCE_RECEIVE, ANNOUNCE_RELAY, DESCRIBE, SETUP, PLAY, RECEIVE 5.6 Security Issues As mentioned earlier there are two main security concerns: The server may implement RTSP authentication with the Auth header. Authorization may be implemented by other means. In order to support media rights and distribution rights issues the source should not send content to an unauthorized or unauthenticated client. Security issues are orthogonal - and are probably not as much of a concern. Typically the source or relay node would generate the SDP to a set of downstream relay nodes. The reasons why security is probably not a huge concern are: (a) The list of relay nodes is likely to be configured manually - implies that arbitrary hosts won't be contacted. (b) The upstream server can control which SETUP/PLAY requests it can serve, and hence ensure authorized access. (c) ANNOUNCE is over RTSP over TCP, and intercepting TCP is not easy. Also downstream relay nodes can be configured to accept ANNOUNCE messages from a set of known hosts. Security concerns can be addressed if both the source/broadcaster and the server implement some authentication/authorization capabilties. 5.7 Use Cases * N-tier relay with Pull only Interior and edge nodes within the same network with no firewalls between them. When the source and servers are all part of the same network, with no firewalls between them, an n-tier relay using Pull mechanism can be set up. Source sends ANNOUNCE to Server; Server sends SETUP/PLAY to source; Source sends media to server. Server delivers streams to its recipients. * N-tier relay with Push only Interior relay node or source behind a firewall; edge node outside the firewall. In the case where the firewall restricts all access from entities outside the firewall, the Pull model cannot be implemented by the Edge node to access media from a relay node within the firewall. In such cases, the interior relay node has to use Push mechanism to send the streams over to the edge node. Source/Server sends ANNOUNCE, SETUP_RECEIVE and RECEIVE to edge node outside the firewall, and then sends streams over TCP to edge node. Edge Node delivers streams over UDP or TCP to its recipients. * N-tier relay with Push and Pull Source with partial RTSP implementation and servers as relay nodes makes up this topology. At the first tier, the source can use Push to send content to the servers. The servers in other tiers can use Pull to access streams from the upstream relay nodes. 6.0 Summary This document identifies the main issues in broadcast and relay of stored and live content and proposes two relay modes, Reflection and Translation, two mechanisms, Pull and Push. These modes and mechanisms together with the automatic publish mechanisms can enable a wide variety of n-tier relays. Several important use cases of relays have been demonstrated. New RTSP primitives are recommended. - SETUP with mode=receive and a RECEIVE method. This introduce only one new RTSP method, and re-use SETUP with the same semantics as SETUP/RECORD in RFC 2326. If the use of the existing RTSP SETUP method to support Push mechanism, is not desired, then another new RTSP method, SETUP_RECEIVE, is needed. - In addition three RTSP methods, ANNOUNCE, ANNOUNCE_RECEIVE and ANNOUNCE_RELAY are introduced to signal availability of content as well as to signal capability of the relay node. - A few additional RTSP headers are recommended for the purpose of identifying (a) content expiry, (b) relay failover/recovery options, (c) content revocation. These small changes to the core spec would go a long way towards enabling n-tier relays. 7.0 Acknowledgements The authors would like to thank Aravind Narasimhan and Thomas Weng for their feedback. 8.0 References [1] Schulzrinne, H., Rao, A., Lanphier, R., "Real Time Transport Protocol (RTSP)", RFC 2326, April 1998. [2] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. [4] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Narasimhan, A., "Real Time Streaming Protocol (RTSP)", draft-ietf-mmusic-rfc2326bis-05.txt, October 27, 2003. -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 2 19:24:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25502 for ; Tue, 2 Dec 2003 19:24:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKoE-0002Eg-O3 for mmusic-archive@odin.ietf.org; Tue, 02 Dec 2003 19:24:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB30O2UY008588 for mmusic-archive@odin.ietf.org; Tue, 2 Dec 2003 19:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKoE-0002ER-KN for mmusic-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 19:24: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 TAA25494 for ; Tue, 2 Dec 2003 19:23:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKoC-0006M5-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:24:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARKoC-0006M2-00 for mmusic-web-archive@ietf.org; Tue, 02 Dec 2003 19:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKoD-0002Cc-Df; Tue, 02 Dec 2003 19:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARKnR-0002Bz-BD for mmusic@optimus.ietf.org; Tue, 02 Dec 2003 19:23:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25491 for ; Tue, 2 Dec 2003 19:22:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARKnP-0006Lx-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:23:11 -0500 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1ARKnO-0006L6-00 for mmusic@ietf.org; Tue, 02 Dec 2003 19:23:10 -0500 Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Dec 2003 16:22:07 -0800 Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 02 Dec 2003 16:22:37 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 2 Dec 2003 16:22:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Draft MMUSIC Minutes Date: Tue, 2 Dec 2003 16:22:38 -0800 Message-ID: Thread-Topic: [MMUSIC] Draft MMUSIC Minutes Thread-Index: AcO38R2UepfCLOnVRV2sPArfTnd16ABQVYyw From: "Orit Levin" To: "Joerg Ott" , , X-OriginalArrivalTime: 03 Dec 2003 00:22:43.0037 (UTC) FILETIME=[916630D0:01C3B933] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Unfortunately, I couldn't participate in the last MMUSIC meeting. Reading the minutes, I found this one peculiar: ------------------ * Semantics are undefined for multiple "m=3D" lines with the same port and "c=3D" The interpretation should go into the SDP-new draft as a clarification. There are minor implications on the offer-answer examples. Gonzalo Camarillo sent some text, but for a different case (hierarchical encoding). Flemming Andreasen proposed that we simply prohibit this construct. The meeting agreed to the prohibition. ------------------- I am wondering how can you allow for one particular application and = prohibit all the others? For the existing implementations, that don't understand the fid = attribute and the associated grouping, it will appear exactly as the = same case. Orit. -----Original Message----- From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org] On Behalf Of = Joerg Ott Sent: Monday, December 01, 2003 1:56 AM To: mmusic@ietf.org; csp@csperkins.org Subject: [MMUSIC] Draft MMUSIC Minutes Folks, attached are the draft minutes from the MMUSIC WG meeting at the 58th = IETF in MPLS. Please review and post comments to the list. The corresponding slides can be retrieved from http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ppt.zip http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-pdf.zip http://www.dmn.tzi.org/ietf/mmusic/58/slides/58-mmusic-slides-ps.zip Thanks, Joerg 58th IETF: MMUSIC Minutes ------------------------- Reported by Tom Taylor and Colin Perkins. MMUSIC met on Friday morning, November 14. The meeting was chaired by = J=F6rg Ott and Colin Perkins = . The agenda was accepted with two minor changes: a discussion of Source = and Sink SDP attributes was added, and the discussion of SDP parameters = for H.263 and H.261 options took place in AVT instead. Introduction and Status Update ------------------------------ J=F6rg Ott gave an introduction and status update. The working group has = had one RFC published since the last meeting: the RTCP attribute for SDP = (RFC 3605 ), and = draft-ietf-mmusic-sdpng-trans-04.txt is with the RFC Editor. The IESG = has reviewed draft-rajeshkumar-mmusic-gpmd-03.txt and suggested some = changes. The authors are considering these, and will produce an update. Colin Perkins has updated the revision to SDP (draft-ietf-mmusic-SDP-new-15.txt) to reflect IESG comments, = implementing the changes suggested at the 57th IETF meeting. The working = group was urged to review the draft to make sure the latest changes = haven't broken anything. Some discussion took place: * There was a question on the time scale for SDP-new approval. The chairs expect an immediate WG review, then off to the IESG. Volunteers were requested for an in-depth review. They were asked to send an E-mail to Joerg to indicate that they were volunteering. * Jon Peterson indicated that he was still worried about the "k=3D" line text. The problem is that the existing text has a normative dependency on informative text: "SHOULD NOT use in absence of ". * There is a problem with the text media type: it's widely used, and referenced in RFC 2327 , but got missed from the original IANA registry for SDP top-level types. We could do it indirectly by putting it into SDP-new. Interested parties are asked to send text to be added to sdp-new for the purpose. Future SDP extensions are strongly discouraged by the WG charter. * Semantics are undefined for multiple "m=3D" lines with the same port and "c=3D" The interpretation should go into the SDP-new draft as a clarification. There are minor implications on the offer-answer examples. Gonzalo Camarillo sent some text, but for a different case (hierarchical encoding). Flemming Andreasen proposed that we simply prohibit this construct. The meeting agreed to the prohibition. The source filter (draft-ietf-mmusic-sdp-srcfilter-05.txt) and comedia (draft-ietf-mmusic-sdp-comedia-05.txt) drafts have been reviewed by the = area director, and need to be updated. The new SDP bandwidth parameters (draft-ietf-mmusic-sdp-bwparam-05.txt) are with the area director, and = an IETF last call is expected shortly. Internet Media Guides --------------------- Requirements: Yuji Nomura discussed requirements for = Internet Media Guides (draft-ietf-mmusic-img-req-00.txt). There are lots = of changes in the latest revision of the requirements draft. A new = background and motivations section has been added. The editor moved in = the problem statement from the old framework draft, but shortened it. Congestion control has been added as a requirement. Security = considerations were added. For the next revision: * requirements will be numbered * terminology will be modified for consistency * clarifications have been requested: many more receivers than senders; senders continually connected, not receivers; and the tradeoff between customization and scalability The revised draft is coming out in the next few weeks. The authors = expect it to be ready for Last Call shortly after that. Framework: Pekka Luoma discussed the IMG = framework (draft-nomura-mmusic-img-framework-02.txt). This is an = individual submission, since it missed the cutoff; a working group draft = will be submitted shortly after the meeting. Changes from the last = version are as follows: * The use cases in the latest version of the draft were extended to include content-oriented use cases. * A section has been added to discuss the applicability of existing protocols. * New section 6.3 summarizes the outstanding needs that existing protocols do not seem to supply: o need for a multicast transport protocol o need to specify how to use specific unicast transport protocols in this application o specification of the "metadata envelope", a new term for an existing concept in the framework that gives independence from transport protocol and metadata format o agreement on the basic metadata models (informative only) Next steps are an editorial cleanup and a new section outlining what = pieces of the work are in IETF scope (the transport protocols and = transfer envelope) and out of scope (the data models and application = specific metadata). It was suggested that an IMG metadata identifier is = needed, likely a URI to differentiate between complete specification, = delta, and filter. J=F6rg suggested avoiding the term "metadata" = altogether, since it causes confusion. Magnus Westerlund remarked that = this was not exactly a framework document. Colin suggested an offline = discussion on this point. Magnus will comment by E-mail. Rod Walsh indicated that whether changes = use the same syntax as the original announcements is still an open = question. It is not clear how reusable the syntax may be. Target is to have WG Last Call in December. Other issues Rod Walsh outlined some open technical issues and design choices = relating to the IMG work: * There are a number of design choices for transport protocols; for multicast, ALC/FLUTE is a very good candidate. * The Subscribe (unicast) model can be handled by SIP and SIP events. * The Metadata Envelope could be: a. XML file/wrapper, or b. header extension of transport protocols. Both? * Data types and channelization: could correlate data type and transport channel? Or could divide delivery over multiple channels? There is a middlebox authentication and integrity issue, since a = middlebox could invalidate the sender signature in some cases (by = performing header modification). Various possible solutions exist: trusted middlebox; middlebox could inform the sender of its change and = request re-signing; middlebox could sign the data. Jonathan Rosenberg = asked whether in this discussion = "middlebox" connoted a NAT or firewall, or whether it simply meant some = router in the abstract? Rod confirmed that the latter meaning was = intended. Jonathan advised him not to call it a middlebox, to avoid = confusion. Alternative IP versions for SDP ------------------------------- Gonzalo Camarillo outlined the = Alternative IP Versions Semantics for the SDP Grouping Framework = (draft-camarillo-mmusic-alt-02.txt). The proposed IPV extension is = backward compatible. Dual-stack hosts are strongly encouraged to = implement IPV. The question is whether to make it a WG item? Flemming Andreassen suggested that text was needed to clarify the = relationship to ICE. He noted that the key point of the extension is to = avoid establishing multiple media streams. That said, could the = extension be applied to abstract properties, beyond IPv4 vs IPv6? Gonzalo confirmed that it could. Jonathan Rosenberg affirmed that the = draft does need text to make the relationship to ICE clear. It was = suggested that IPV may not be the appropriate name. The consensus of the group was to make this a WG draft. Source and Sink SDP attributes ------------------------------ Gonzalo Camarillo discussed SDP = source and sink attributes (draft-camarillo-sipping-transc-3pcc-00.txt). This draft came from the transcoding design team in SIPPING. It deals = with a problem in the routing of media types, which is really a service = location problem. J=F6rg suggested that this was really a small subset of the XCON WG = topic area. The draft raises a potential problem: signalling by SDP = could conflict with other media policy mechanisms. Gonzalo agreed that = the team would clarify whether should use the more general mechanism or = whether this one is justified. Security Descriptions --------------------- Flemming Andreassen reviewed the changes in the latest revision of the = security descriptions draft (draft-ietf-mmusic-sdescriptions-02.txt). The draft has been generalised into a core framework and an SRTP = specific part, and numerous editorial changes and clarifications have = been included. In detail, the changes are: * offer/answer highlights differences between unicast/multicast and the initial/subsequent offer * rekeying is addressed via offer/answer; everything can be changed * additional rules and considerations for communicating the SRTP SRC parameter * removed the SRTP "use" parameter, which is now inferred from context * added Window-Size Hint and to SRTP profile * more rules for extensions... * updated IANA considerations and grammer There are still four open issues. Issue 1 was with multicast: * Shared vs. per-participant key? * When a key is shared, the streams need unique SSRCs per destination. * If per-participant keys are used, each participant has to convey his/her key separately. * How to support for hierarchical layered encoding schemes is another multicast issue. Flemming was not sure there is a single good solution. The proposal was = made that multicast streams should be left for further study, and not = included in this draft. Jon Peterson wondered if we had found the = logical dividing line between unicast and multicast. Jonathan Rosenberg = wanted to be sure the solution is mature before deciding this. J=F6rg = indicated that he would like to progress the draft, since it addresses = fairly urgent issues. There was agreement that it was reasonable to = leave multicast for further study. Issue 2 was several problems with respect to the SRC parameter. Most of = them are multicast based, hence can be left aside for now. There are = still the questions of: * how many crypto contexts can sdescriptions establish? * handling SSRC collisions. There was a suggestion to remove the SSRC part and support single = context only. However, Magnus Westerlund pointed out that you can get = multiple SSRC from the same host. The decision was therefore to keep the = SSRC part in the document for the moment. Issue 3 (on Flemming's slides) was purely multicast, and so was skipped. Issue 4 was the "Use" parameter which was removed, since it led to = complexity and could be inferred from context. Is there any need for it? No feedback from the room - please read and comment. Flemming expects to provide an update by December. There are no other = known issues. Should it go to WG Last Call? Need volunteers to give it a = thorough review. Magnus volunteered on the spot. Jon Peterson is to = organize as Security Area review. Security Preconditions ---------------------- Flemming Andreassen outlined draft-andreasen-mmusic-securityprecondition-00.txt on security = preconditions. The problem: an ambiguity in security description = selection. There is a need to block sending until the ambiguity is = resolved. Should this be a WG work item? Gonzalo Camarillo suggested the WG look at RFC 3329 (Security Mechanism = Agreement for the Session Initiation Protocol (SIP)) as a model to = ensure not they are not introducing a security risk. Jon Peterson = suggested the WG look at the possible use of security associations = between hosts. He argued against the presence of security preconditions = in RFC 3312 because of = bootstrapping concerns. He was trying to recall detailed arguments: we = had better look at the archives. Resolution: think about it a bit more. Interactive Connectivity Establishment -------------------------------------- Jonathan Rosenberg discussed ICE (draft-ietf-mmusic-ice-00.txt), which = was accepted as an MMUSIC work item in Vienna. Since then, the draft has = been rewritten to make it protocol independent: * generic session establishment protocol; * defined semantics in terms of that protocol; * ICE compliance defined in terms of mapping to generic protocol; * showed mapping for SIP (RTSP and H.323 are other possibilities, for future work) Another change is that it is necessary to know, through configuration, = which is a public TURN relay (there may be non-public ones; public one = is default). ICE now uses the TURN SEND mechanism to tell the relay to = send a packet to a particular address-port; this can only be used before = lockdown and is needed in inter-enterprise cases. Jonathan walked through a call flow. Magnus was concerned about a packet = loss case after lockdown, before return to client. Jonathan will add a = case to cover this. A question was asked: can a binding be removed? TURN = can, but not ICE. Lockdown cannot be removed: keep things simple. In the = rewrite, Jonathan removed the massive call flows section from the draft: SIP usage is not the point. Open issues include getting TCP to work (needs a connect method, and = there is the issue: demultiplexing of STUN and data on the connection - = perhaps try to avoid it by restricting functionality) and prioritization = of addresses, basically pushing routing to endpoints. Is there a better = way? Flemming Andreasen, without being specific, suggested that there = may be something in the middle that can handle routing better. Issues to be addressed: * RTSP mapping? Jonathan lacks expertise and time... * Sequential send attempts: Magnus suggested to do the semantics only once, but Jonathan warned that we must not make assumptions about topology. * Use of multiple STUN servers? There was discussion on extra round trips. Jonathan indicated he would be pleased to see a better solution. There are tradeoffs: effficiency vs. reliability and safety. We can continue to think about optimizations (such as assuming the RTSP server is on the public network), but with great care. * Is it OK to have username/password in clear? * SDP ALT parameter conflict with 3GPP: Jonathan will fix. Jon Peterson noted that he wouldn't mind more warning from 3GPP. The IESG is working on a liaison process to achieve this. RTSP ---- Magnus Westerlund presented a number of changes incorporated in the = latest draft version of RTSP (draft-ietf-mmusic-rfc2326bis-05.txt). Further changes have been agreed, but are not yet documented: * Implicit Redirect using new 3xx code to get SDP for supporting terminals. A feature tag will associated with this for backward compatibility. * Address class in "c=3D" needs to be checked. * Caching of methods is unspecified * Aggregate control URI deriving will be unspecified * Clarify the usage of SDP "a=3Drange" for TiVo type of devices * The server MAY close the TCP connection after receiving the 2xx message for a REDIRECT request * To write something about request to response time limitations. Keep the specification simple, details to be worked out. * ABNF to be collected in a single chapter * Issues with changing transport parameters using SETUP * Should the Location header work as base URI for requests with REDIRECT without SESSION header * Request/response time is not limited; needs clarification There are few open issues, but lots of editorial stuff to clean up. The = team will try to edit out all known bugs by the end of year. A clean-up = review can be held from January to March, with WG Last Call by March. The teleconferences will continue, starting on 3rd December. RTSP NAT -------- Thomas Zeng discussed RTSP NAT traversal = (draft-ietf-mmusic-rtsp-nat-01.txt). There is still lots of work to do = on the -01 draft based on Vienna comments, but work on the core RTSP = spec took priority. Current focus is to clarify the requirements: * MUST work for all flavors of NAT, including symmetric * MUST work for firewalls, including those with ALGs * SHOULD have minimal impact on clients in the open and not dual hosted * SHOULD be simple to use/implement * SHOULD be secure Jonathan cautioned on the wording of requirements with respect to firewalls: make sure the aim is to support administrative control. There is an issue with dual-hosted clients. Thomas proposed to add a = mechanism to support them: many RTSP servers won't allow such clients, = to prevent DDOS attacks. Jon Peterson suggested that the most important = task at hand is to explain the problem in great detail. Moving forward the next revision will clarify "statement of intention" and provide list of requirements. Will also remove any solutions = requiring protocol extensions to a separate draft. Jonathan noted that = some mechanisms can be provided on the basis of "required to implement, = not required to use" RTSP END-OF-STREAM proposal --------------------------- Thomas Zeng discussed the END-OF-STREAM proposal for RTSP = (draft-zeng-mmusic-rtsp-end-of-stream-01.txt). Background: RTCP BYE is = awkward; would like to be able to reuse SSRC. Lately the RTSP team has = been finding a requirement to push various items to the client: END-OF-STREAM, session descriptions and updates, error events. Some = earlier drafts have been written in the area. Strawman proposal: extend RTSP, adding a Server-to-Client method with = feature tag. There was a recent suggestion to use ANNOUNCE for the = End-of-Stream application. Should this be generalized for other = information? Tom Marshall suggested using a SET parameter. J=F6rg didn't = think the semantics felt right. Regarding the strawman proposal: J=F6rg would like to avoid having to = respecify connection management for the Server-to-Client direction. This = was more a matter that the client should keep the connection up to = receive notifications. Thomas provided an example of possible syntax. Magnus expressed a = concern with the "bytes" specification in Range; this is a conflict. The = example will be cleaned up. The next step is expand scope of draft to cover ANNOUNCE as an extension = of the core specification. Should this be a WG item? Magnus and Colin = both suggested further work before making this decision. We can decide = on the mailing list after the next revision. We might consider pulling = back this capability into the main specification. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 3 05:20:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08439 for ; Wed, 3 Dec 2003 05:20:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU7G-0004lZ-9m for mmusic-archive@odin.ietf.org; Wed, 03 Dec 2003 05:20:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3AKGvq018319 for mmusic-archive@odin.ietf.org; Wed, 3 Dec 2003 05:20:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU7E-0004lO-0x for mmusic-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 05:20:16 -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 FAA08404 for ; Wed, 3 Dec 2003 05:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARU7A-0005Xf-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 05:20:12 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARU79-0005XX-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 05:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU70-0004jR-W7; Wed, 03 Dec 2003 05:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARU69-0004iV-IN for mmusic@optimus.ietf.org; Wed, 03 Dec 2003 05:19:09 -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 FAA08384 for ; Wed, 3 Dec 2003 05:18:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARU66-0005X8-00 for mmusic@ietf.org; Wed, 03 Dec 2003 05:19:06 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARU65-0005X5-00 for mmusic@ietf.org; Wed, 03 Dec 2003 05:19:05 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB3AJ5I2026129; Wed, 3 Dec 2003 11:19:05 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW6GYGSF; Wed, 3 Dec 2003 11:19:05 +0100 Message-ID: <3FCDB895.7070806@ericsson.com> Date: Wed, 03 Dec 2003 11:19:01 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geetha Srikantan CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP transport negotiation References: <1066800352.27652.3.camel@jamba> <3FCC5294.8040207@ericsson.com> <1070409596.15015.78.camel@jamba> In-Reply-To: <1070409596.15015.78.camel@jamba> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Geetha, Comments inline. This mail has resulted in the opening of the following source forge issue has been created: http://rtsp.org/bug853175 http://rtsp.org/bug853178 http://rtsp.org/bug853184 Geetha Srikantan wrote: > hi Magnus, > > Thanks for the comments. I should have clarified that this > document was mainly intended to address transport negotiation > in play state. Your point is well taken, that we do need to specify > transport negotiation when a stream is setup too. > Good, I think that there is need to also consider the differences between initial SETUP transport negotiation and changing in Play state. > Also I'm ok with using dest_addr, src_addr, client_port, server_port > instead of the new parameters in my document. > I think you haven't really understood tat dest_addr, replaces the destination together with client_port, and src_addr, replaces source and server_port as dest_addr carries one ore more address+port. >>>3. Transport Parameters Excluded from Negotiation >>> >>> It is recommended that the following parameters be excluded from the >>> negotiation process. >>> >>> mode >>> url >>> unicast/multicast >>> layers >>> ttl >>> ssrc >>> destination >>> source >>> >>> >>> As the "mode" parameter is restricted to a single value in the >>>current draft, it can be excluded. >> >>I think that this is a very fundamental parameter if also record is add >>again in the future. >> > > > I agree that mode is an important parameter, however I am wondering > if it would be reasonable to change from say mode=play to mode=record > during play state? > I guess this would enable Tivo-like functionality on a playing session, > is that what you had in mind? > If that's the case, this switch in parameter should be allowed. > I think this is something we need to consider further. In the core specification we don't have any other mode than play defined so we can probably put it in the list of attributes that are not changed, and if other modes becomes available need to be defined. In regards to TiVo sessions, you mean cases when such functionality would be done through a server, for example for a live session. This is quite a change in RTSP perspective for the session. From being sending media from a server local source to a client it shall instead save the stream that for the client looks like a local server resource. For sessions with multiple media streams the change should happen simultaneously for all streams which is difficult for RTSP. > >>>4. Negotiable Transport Parameters >>> >>> Hence there are three main conditions that require transport >>>negotiation for unicast: >>> >>> * client IP address changes >>> * client wants to switch transport from UDP -> TCP >>> * client wants to switch transport from TCP -> UDP >>> >>> Changes in the client IP address can be indicated using a new >>>"client_ip" parameter. Hence the parameters that are impacted by >>>transport negotiation are: >>> >>> client_ip >>> interleaved >>> client_port >>> server_port >>> >> >>I think we should clarify client ip and port with destination >>address/port. I also think an important parameter to discuss in this >>context is the lower layer transport. I would think that the transport >>protocol and profile are not likely to change. >> > > > So we do not allow changing: > transport protocol and profile. > > We allow changing: > client ip and port > lower layer transport > server port > > Server port may change only as a result of client address/port change. > Since the RTP/RTCP client and server endpoints need to be unique. > I agree that the server ports need to be possible to change, otherwise we will create quite difficult problems for us in the future if RTSP servers becomes part of NATed end-points, where a change of destination would very likely result in a change of the visible address/port for the client. >>>6. Examples >>> >>>6.1 Client IP Address Changes >>> >>> C->S: DESCRIBE rtsp://foo/twister.sdp RTSP/1.1 >>> CSeq: 1 >>> >>> S->C: RTSP/1.0 200 OK >>> CSeq: 1 >>> Content-Type: application/sdp >>> Content-Length: 164 >>> >>> v=0 >>> o=- 2890844256 2890842807 IN IP4 172.16.2.93 >>> s=RTSP Session >>> i=An Example of RTSP Session Usage >>> a=control:rtsp://foo/twister >>> t=0 0 >>> m=audio 0 RTP/AVP 0 >>> a=control:rtsp://foo/twister/audio >>> m=video 0 RTP/AVP 26 >>> a=control:rtsp://foo/twister/video >>> >> >>There shall be a "c=" line somewhere. Then a question, how does the >>client learn that if this session is multicast that it really is? Is >>that totally dependent on that the "c=" address is of multicast type? >> > > > Yes, the c= line is missing..thanks for pointing it out. > That's usually how the client determines if it's > a multicast - by looking at the address type in the c= line. > As a related problem, how does a client learn that a session can be distributed as multicast, but no multicast address is pre-assigned to the session when the SDP is published. It seems that we can't quite express this case. Or does someone see a possibility? Another interesting use case is if a multicast conference invites a RTSP server into the session and the controlling entity request the server to play to the already used multicast addresses. Does the server needs to be able to announce this support, or is it something the client simply ask for and the server either succeeds or fails? > >>> C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 >>> CSeq: 2 >>> Transport: RTP/AVP;unicast;client_port=8000-8001 >> >>If one would like to have a good example of initial "negotiation" then >>the client should include multiple transport specs for the server to >>choose from. >> > > > That seems reasonable. What would be the preferred format for that. > Some thing like this: > > C->S: SETUP rtsp://foo/twister/audio RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=8000-8001, > RTP/AVP/TCP;interleaved=0-1 > > You need a "unicast" in the RTP/AVP/TCP transport specification also. Otherwise you are defaulting to multicast over TCP which can be a bit difficult. >> >>> C->S: PLAY rtsp://foo/twister RTSP/1.0 >>> CSeq: 4 >>> Range: npt=0- >>> Session: 12345678 >>> >>> S->C: RTSP/1.0 200 OK >>> CSeq: 4 >>> Session: 12345678 >>> RTP-Info: url=rtsp://foo/twister/video; >>> seq=9810092;rtptime=3450012, >>> url=rtsp://foo/twister/audio;seq=5923;rtptime=22234432 >>> Range: npt=0-30.76 >>> >>>... now change client IP address .... >>> >>> C->S: SETUP rtsp://foo/twister/video RTSP/1.0 >>> CSeq: 5 >>> Transport: RTP/AVP;unicast;client_ip=>> client_port=8002-8003;server_port=9004-9005 >>> Range: npt=5- >>> Session: 12345678 >>> >> >>The parameter is not "client_ip" it is either "destination" or "dest_addr". >> > > I'm ok with using dest_addr. I was not sure if it's ok to re-use > dest_addr, that's why I introduced client_ip (and client_port later). > I don't see that there are any semantic difference between destination address the first time around (initial setup), and the second (changing the parameter). What we perhaps should consider is if the server is required to recheck the transport parameter source and redirect the stream to that destination when a setup request is received. I also thing we must consider the security threats when one implements this behaviour. When one establish a session the right client will be at least be certain that the session goes to the intended address if the destination is included in the SETUP response. However when sending a SETUP request to change the parameter any being able to snoop the traffic can now simply hijack the established session, unless we require authentication within the session. Using TLS for the RTSP messages only provides the security that the randomness of the session ID provides. I think we need to consider the security implications much more. Geetha, can you please start a security section in relation to this. >> >> >>> S->C: RTSP/1.0 200 OK >>> CSeq: 5 >>> Transport: RTP/AVP;unicast;client_ip=; >>> client_port=8002-8003;server_port=9004-9005 >>> RTP-Info: url=rtsp://foo/twister/video; >>> seq=;rtptime=, >>> Range: npt=5-30.76 >>> Session: 12345678 >>> >> >>I also think one should point out why one includes Range here. In >>regards to the RTP-Info, I think that one should primarily indicate the >>RTP sequence number in RTP-Info. Using rtptime combined with "Range" >>might not be the best, because one would normally not intend to change >>anything in the npt <-> RTP TS binding, as it would cause real problems >>for a client during playback. >> > > > I think the concern is that the client may need to re-sync after > transport negotiation. I didn't mean to imply that there would be > a change in the NPT <-> timestamp correspondence. Including > seq and rtptime in RTP-Info would make it easier for the client. > I can rephrase it to say that the server should not change the NPT <=> > timestamp correspondence during transport negotiation. > you would not need a re-sync unless you have changed the NPT <-> RTP TS relation. What does people think? are there situation where there is a clear need to perform re-synchronization. >>> Page 83-83: BNF indicates "client_port" and >>> "server_port" will be indicated as 'port1-port2'. This doesn't seem >>> adequate for the case where the RTP and RTCP ports are non-adjacent >>> (per the new RTP spec rfc 3550). >>> >> >>That is what dest_addr and src_addr are created to address as they allow >>for enumerating any number of address/port constellations in case of >>IP/port based transport. >> > > > Would you please give an example of what this looks like > for non-adjacent RTP and RTCP ports for a stream? > Since RFC 3550 allows non-adjacent ports, the BNF in the current draft > would mean this is written as: > > C->S SETUP rtsp://example.com/foo/bar/bar.rm RTSP/1.0 > CSeq: 2 > Transport: RTP/AVP;unicast;client_port=4588-6129 > > if the RTP port is 4588 and RTCP port is 6129. > > This should not be interpreted as a port range by the server. > That's the problem I was referring to. > > No, the intention of the new dest_addr and src_addr parameter is to replace the usage of client_port and server_port when you have non-adjacent ports. Instead you use in case of RTP dest_addr and provides addr1+port1 and addr2+port2 thus ensuring that also scenarios where you desire delivery of RTCP and RTP to different IP addresses, for example due to NATs doing stupid translation. A new issue with these parameter I haven't thought about before is the need for always including a destination address in the parameter. Is this problematic, and would work better if we add a place holder for indicate: Use the same address as my RTSP message transport connection? I guess it probably makes sense in cases of realm specific IP addresses, and other translation techniques which does not remap the ports only the IP address. > >>> Proposal: >>> client_port: rtp=, rtcp= >>> server_port: rtp=, rtcp= >>> >>Bad Idea from a backwards compatibility stand point. That is why I >>proposed the dest_addr parameter to take care of this and hopefully any >>future problems. However I perhaps should be consider to ensure that any >>type of address can be expressed in this, by doing class, and string >>definition. >> > > > If the client_port and server_port is rephrased to have non-adjacent > ports, then there is no need for the change I suggest. > To be clear, we are not rephrasing the client_port or server_port due to backwards compatibility. You will be required to support the new specification and indicate that to be able to use non-adjacent ports. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 3 07:26:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12595 for ; Wed, 3 Dec 2003 07:26:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARW5H-0002Ry-Up for mmusic-archive@odin.ietf.org; Wed, 03 Dec 2003 07:26:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3CQNSW009412 for mmusic-archive@odin.ietf.org; Wed, 3 Dec 2003 07:26:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARW5H-0002Rg-Nh for mmusic-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 07:26:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12570 for ; Wed, 3 Dec 2003 07:26:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARW5G-0007IA-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 07:26:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARW52-0007Hc-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 07:26:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARW4z-0002LD-7a; Wed, 03 Dec 2003 07:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARW4b-0002J4-9d for mmusic@optimus.ietf.org; Wed, 03 Dec 2003 07:25: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 HAA12507 for ; Wed, 3 Dec 2003 07:25:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARW4a-0007G7-00 for mmusic@ietf.org; Wed, 03 Dec 2003 07:25:40 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ARW4Z-0007G3-00 for mmusic@ietf.org; Wed, 03 Dec 2003 07:25:39 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB3CPcI2007434 for ; Wed, 3 Dec 2003 13:25:38 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW8010XR; Wed, 3 Dec 2003 13:26:05 +0100 Message-ID: <3FCDD63E.8040302@ericsson.com> Date: Wed, 03 Dec 2003 13:25:34 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mmusic@ietf.org Subject: [MMUSIC] RTSP: Telecon 18.00 the 3rd of December with agenda - Updated Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Today is the RTSP telecon. I provide an updated agenda. The changes are both in 2.1 and an addition of paragraph 3.1. Telecon details: Phone number +46 8 71 99500 Participant PIN 67700 Date 12/03/2003 (MM/DD/YYYY) Start Time 18:00 (HH:MM) (CET) Duration 90 minutes Cheers Magnus Westerlund Agenda 1. Opening of meeting and Administrative - Scribe 2. RTSP Core 2.1 Core specification bugs under developement. a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind to write up text b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - Await review from the WG. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Needs text d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - The explicit rules will be removed, possibility will be left open. Needs to be edited in. e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Needs a clarifying definition of Live - Need to check to possibility for TiVo cases. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Conclusion from Minneapolis needs to be edited in: Server MAY drop the connection after it has recieved 200 OK response on a REDIRECT. g. http://rtsp.org/bug770522 - Request to response time is not limited. - Sean has written up text. - Conclusion from Minneapolis: Sean's writeup seems reasonable. Change the timelimit to 2 seconds and make sure that wording is there to indicate server should do this immediately if it know it's going to take a long time. Need motivation example. h. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - Has been removed from spec, awaiting review. i. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - Awaiting review from the WG. j. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - Text sent to mailing list, we will dicuss this, please read https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02030.html k. http://rtsp.org/bug810666 - Removal of SETUP in play state - Clarify in specification that it is unspecified. l. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes - Conclusion from Minneapolis: Should look at address classes in the SDP to figure what protocol to use (need to add SDP section of RTSP). Look at c= line syntax. Multiple c lines can be use in media field? SIP resolution was that multiple c lines should not be used to express multiple connection address. m. http://rtsp.org/bug795314 - Caching of OPTIONS request - conclusion from Minneapolis: Will be declared unspecified. n. http://rtsp.org/bug850256 - When must RTP-Info be included? o. http://rtsp.org/bug850265 - Removed features are unspecified, not forbidden p. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces. - Awaiting write up. q. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one chapter? r. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP. s. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP IP t. http://rtsp.org/bug853178 - Security risk with changing transport parameters u. http://rtsp.org/bug853184 - How to learn servers multicast capabilities 2.2 Tracking of items not require actions currently. These items are for future processing when appropriate. A. http://rtsp.org/bug810681 - The updated specification version number - Awaiting investigation results regarding changes by Aravind. - Question of intentions. 3. RTSP Specifiction Extensions 3.1 Streaming Relays. See MMUSIC mail: https://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg02190.html 3.2 End of Media http://rtsp.org/bug810678 - How to indicate end of media stream - We need to document in the RTSP specification regarding RTP what happens when a source times out a SSRC or receives a RTCP BYE for a source. - Using BYE is not suitable way to indicate the end of the stream. The motivation for this can be seen in Thomas proposal. - The creation of a new proposal. 3.3 RTSP and NAT issues - Requirements Priorities: 1. Server is deployed in open network. 2. Server behind firewall next. 3. If a client is not dual hosted, it should not have to deal with additional protocols. 4. Must have defense against DOS 5. Security. 6. MUST deal with symmetric nat. 7. ALG. The firewall traversal should not interfere with ALGs. 8. Advise to ALG writers not to screw it up. Review and clarify. - Protocol extension proposals What proposals do we have, and which people are sheeparding. - Update to RTSP and NAT WG draft * ALG recommendation 4. Next meeting 5. Meeting closed. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 3 12:34:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24735 for ; Wed, 3 Dec 2003 12:34: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 1ARatC-0002Da-QH for mmusic-archive@odin.ietf.org; Wed, 03 Dec 2003 12:34:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3HYE7s008522 for mmusic-archive@odin.ietf.org; Wed, 3 Dec 2003 12:34:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARatC-0002DN-LQ for mmusic-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12:34:14 -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 MAA24694 for ; Wed, 3 Dec 2003 12:33:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARatB-0004re-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 12:34:13 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARatA-0004rb-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 12:34:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARasz-0002Cf-DY; Wed, 03 Dec 2003 12:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARas3-0002Aw-4A for mmusic@optimus.ietf.org; Wed, 03 Dec 2003 12:33: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 MAA24634 for ; Wed, 3 Dec 2003 12:32:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARas1-0004pr-00 for mmusic@ietf.org; Wed, 03 Dec 2003 12:33:01 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARas1-0004pT-00 for mmusic@ietf.org; Wed, 03 Dec 2003 12:33:01 -0500 Received: from cisco.com (rtp-vpn2-197.cisco.com [10.82.240.197]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hB3HWHxg028631; Wed, 3 Dec 2003 12:32:20 -0500 (EST) Message-ID: <3FCE11FF.2CDFC888@cisco.com> Date: Wed, 03 Dec 2003 11:40:31 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Orit Levin CC: Joerg Ott , mmusic@ietf.org, csp@csperkins.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > Unfortunately, I couldn't participate in the last MMUSIC meeting. > Reading the minutes, I found this one peculiar: > ------------------ > * Semantics are undefined for multiple "m=" lines with the same port > and "c=" The interpretation should go into the SDP-new draft as a > clarification. There are minor implications on the offer-answer > examples. Gonzalo Camarillo > sent some text, but for a different case (hierarchical > encoding). Flemming Andreasen proposed > that we simply prohibit this construct. The meeting agreed to the > prohibition. > ------------------- > > I am wondering how can you allow for one particular application and prohibit all the others? We need to make it well-defined one way or the other. We had a thread on this issue titled "Multiple 'm' lines with the same port number" at the end of April 2003, where the general consensus seemed to be in-line with the above. The problem I have with the interpretation saying that you *can* have multiple "m=" lines with the same address and port is that it raises all kinds of issues that have not been dealt with. For example: - Can I use different top-level MIME media types and/or transports for these "m=" lines ? - How does offer/answer deal with them ? Present text suggests that an "m=" line corresponds to a media stream, however this suggests something different. - What about media stream parameters applied to one of these "m=" lines, but not the other, or applied inconsistently ? For example, what if I set one of them to "inactive" and the other to "sendrecv", specify one SRTP key for of them, and another for the other, etc. What am I allowed to do, what not, and what do I do if it is violated ? The list goes on. In short, there is lot of issues that would need to be dealt with before this would be well-defined and interoperable, and that suggests strongly that it either was not implied by the original spec (which the above referenced thread seemed to converge on) or was not very well thought out. The end result is the same; I would not expect old implementations to understand these semantics in any kind of interoperable way and hence it should not be part of the updated spec either (new functionality). > > For the existing implementations, that don't understand the fid attribute and the associated grouping, it will appear exactly as the same case. > That is different. Fid is an extension, not part of the core SDP spec. Also, fid has specified ways of recognizing and recovering from answerers that to does not support the extension. -- Flemming > > Orit. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 3 12:36:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24843 for ; Wed, 3 Dec 2003 12:36:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARauy-0002MN-Mj for mmusic-archive@odin.ietf.org; Wed, 03 Dec 2003 12:36:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB3Ha48R009064 for mmusic-archive@odin.ietf.org; Wed, 3 Dec 2003 12:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARauy-0002M7-Ec for mmusic-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 12:36: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 MAA24828 for ; Wed, 3 Dec 2003 12:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARauw-0004uj-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 12:36:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARauw-0004ue-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 12:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARaux-0002KW-BV; Wed, 03 Dec 2003 12:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARauq-0002Ia-Cp for mmusic@optimus.ietf.org; Wed, 03 Dec 2003 12:35:56 -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 MAA24812 for ; Wed, 3 Dec 2003 12:35:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARauo-0004uI-00 for mmusic@ietf.org; Wed, 03 Dec 2003 12:35:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ARauc-0004tW-00 for mmusic@ietf.org; Wed, 03 Dec 2003 12:35:42 -0500 Received: from cisco.com (rtp-vpn2-197.cisco.com [10.82.240.197]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hB3HZ0DM029291; Wed, 3 Dec 2003 12:35:03 -0500 (EST) Message-ID: <3FCE11FF.2CDFC888@cisco.com> Date: Wed, 03 Dec 2003 11:40:31 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Orit Levin CC: Joerg Ott , mmusic@ietf.org, csp@csperkins.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit Levin wrote: > Unfortunately, I couldn't participate in the last MMUSIC meeting. > Reading the minutes, I found this one peculiar: > ------------------ > * Semantics are undefined for multiple "m=" lines with the same port > and "c=" The interpretation should go into the SDP-new draft as a > clarification. There are minor implications on the offer-answer > examples. Gonzalo Camarillo > sent some text, but for a different case (hierarchical > encoding). Flemming Andreasen proposed > that we simply prohibit this construct. The meeting agreed to the > prohibition. > ------------------- > > I am wondering how can you allow for one particular application and prohibit all the others? We need to make it well-defined one way or the other. We had a thread on this issue titled "Multiple 'm' lines with the same port number" at the end of April 2003, where the general consensus seemed to be in-line with the above. The problem I have with the interpretation saying that you *can* have multiple "m=" lines with the same address and port is that it raises all kinds of issues that have not been dealt with. For example: - Can I use different top-level MIME media types and/or transports for these "m=" lines ? - How does offer/answer deal with them ? Present text suggests that an "m=" line corresponds to a media stream, however this suggests something different. - What about media stream parameters applied to one of these "m=" lines, but not the other, or applied inconsistently ? For example, what if I set one of them to "inactive" and the other to "sendrecv", specify one SRTP key for of them, and another for the other, etc. What am I allowed to do, what not, and what do I do if it is violated ? The list goes on. In short, there is lot of issues that would need to be dealt wiX-Mozilla-Status: 0009e well-defined and interoperable, and that suggests strongly that it either was not implied by the original spec (which the above referenced thread seemed to converge on) or was not very well thought out. The end result is the same; I would not expect old implementations to understand these semantics in any kind of interoperable way and hence it should not be part of the updated spec either (new functionality). > > For the existing implementations, that don't understand the fid attribute and the associated grouping, it will appear exactly as the same case. > That is different. Fid is an extension, not part of the core SDP spec. Also, fid has specified ways of recognizing and recovering from answerers that to does not support the extension. -- Flemming > > Orit. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 3 23:13:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26413 for ; Wed, 3 Dec 2003 23:13: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 1ARkrR-00059c-Mg for mmusic-archive@odin.ietf.org; Wed, 03 Dec 2003 23:13:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB44D5Nq019809 for mmusic-archive@odin.ietf.org; Wed, 3 Dec 2003 23:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkrR-00059Q-4X for mmusic-web-archive@optimus.ietf.org; Wed, 03 Dec 2003 23:13: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 XAA26404 for ; Wed, 3 Dec 2003 23:12:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkrP-0001D7-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 23:13:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARkrO-0001D4-00 for mmusic-web-archive@ietf.org; Wed, 03 Dec 2003 23:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkrK-00058s-KO; Wed, 03 Dec 2003 23:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARkrE-00058h-PF for mmusic@optimus.ietf.org; Wed, 03 Dec 2003 23:12:52 -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 XAA26395 for ; Wed, 3 Dec 2003 23:12:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARkrC-0001Ce-00 for mmusic@ietf.org; Wed, 03 Dec 2003 23:12:50 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1ARkrB-0001Cb-00 for mmusic@ietf.org; Wed, 03 Dec 2003 23:12:49 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Wed, 03 Dec 2003 20:12:10 -0800 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (fetchmail-6.2.0) for robla@localhost (single-drop); Wed, 03 Dec 2003 20:12:10 -0800 (PST) Received: from sc8-sf-mx2.sourceforge.net ([::ffff:66.35.250.206]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by capefear.real.com with esmtp; Wed, 03 Dec 2003 20:08:38 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=sc8-sf-list1.sourceforge.net) by sc8-sf-mx2.sourceforge.net with esmtp (TLSv1:AES256-SHA:256) (Exim 4.24) id 1ARkml-0006ie-SP for robla@real.com; Wed, 03 Dec 2003 20:08:16 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=projects.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.24) id 1ARkml-0004v3-HO for robla@real.com; Wed, 03 Dec 2003 20:08:15 -0800 Date: Wed, 03 Dec 2003 20:05:47 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.9-sf.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Old-To: rtspspec-bugs@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Score: 0.3 (/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on capefear.real.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=2.60 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #110 - 7 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is an automatic digest of bugs submitted and changed on the RTSP bug tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rtspspec-bugs digest" Today's Topics: 1. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net) 2. [ rtspspec-Bugs-853178 ] Security reisk with changing transport parameters (SourceForge.net) 3. [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP (SourceForge.net) 4. [ rtspspec-Bugs-853178 ] Security risk with changing transport parameters (SourceForge.net) 5. [ rtspspec-Bugs-853184 ] How to learn servers multicast capabilities (SourceForge.net) 6. [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 (SourceForge.net) 7. [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification (SourceForge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 02:00:50 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP Bugs item #853175, was opened at 2003-12-03 11:00 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=853175&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Dest_addr needs indicator for using RTSP IP Initial Comment: The transport header parameters dest_addr and src_addr that has been introduced to cope with non-adjacent ports and same IP address for media transport protocols like RTP that requries multiple streams to work. There seem to be motivated to ensure that previously allowed behavoir to exclude giving a destination address and instead have the server to deliver the media to the source ip of the RTSP carrying TCP connection. To enable this with the new paramters some changes are required, the 05 version requries you to put in some address. So either we change this, or define a indicator for this behavior. This will allow that clients in private address spaces using some addesstranslation techniuqes to use them without being requried to learn their external address. Examples of such translation are realm specific IP and NAT's without port translation. Please do also note that for these translations the usage of public STUN server works. However it should be noted the lack of destination address is not without its consideration. IF an RTSP proxy is used, it will be requried to add the destination address, before forwariding any SETUP request. There are also need to furhter review if any furhter security considerations are needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 02:07:53 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853178 ] Security reisk with changing transport parameters Bugs item #853178, was opened at 2003-12-03 11:07 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=853178&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Security reisk with changing transport parameters Initial Comment: To allow that transport parameters are changed during a session will make hi-jacking attacks increadibly simple, unless furhter protection mechanisms are used. The Attack: The client has established a RTSP session with some media stream to a server. The attack is capable to read the RTSP messages between client and server. Thus gaining the session ID. When the session is playing the attack can be simply sending SETUP messages change the delivery to the attacker instead. Prevention techniques: Encrypting RTSP messages will prevent the attacker from easily learning the RTSP session ID, thus providing a protection equal to the randomness of the session ID. The real fix, requiring authentication of client when performing these changes to the session. Discussion need to determine what required security protection that are needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 02:10:32 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853175 ] Dest_addr needs indicator for using RTSP IP Bugs item #853175, was opened at 2003-12-03 11:00 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Nobody/Anonymous (nobody) Summary: Dest_addr needs indicator for using RTSP IP Initial Comment: The transport header parameters dest_addr and src_addr that has been introduced to cope with non-adjacent ports and same IP address for media transport protocols like RTP that requries multiple streams to work. There seem to be motivated to ensure that previously allowed behavoir to exclude giving a destination address and instead have the server to deliver the media to the source ip of the RTSP carrying TCP connection. To enable this with the new paramters some changes are required, the 05 version requries you to put in some address. So either we change this, or define a indicator for this behavior. This will allow that clients in private address spaces using some addesstranslation techniuqes to use them without being requried to learn their external address. Examples of such translation are realm specific IP and NAT's without port translation. Please do also note that for these translations the usage of public STUN server works. However it should be noted the lack of destination address is not without its consideration. IF an RTSP proxy is used, it will be requried to add the destination address, before forwariding any SETUP request. There are also need to furhter review if any furhter security considerations are needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853175&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 02:10:54 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853178 ] Security risk with changing transport parameters Bugs item #853178, was opened at 2003-12-03 11:07 Message generated for change (Settings changed) made by magwes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) >Assigned to: Nobody/Anonymous (nobody) >Summary: Security risk with changing transport parameters Initial Comment: To allow that transport parameters are changed during a session will make hi-jacking attacks increadibly simple, unless furhter protection mechanisms are used. The Attack: The client has established a RTSP session with some media stream to a server. The attack is capable to read the RTSP messages between client and server. Thus gaining the session ID. When the session is playing the attack can be simply sending SETUP messages change the delivery to the attacker instead. Prevention techniques: Encrypting RTSP messages will prevent the attacker from easily learning the RTSP session ID, thus providing a protection equal to the randomness of the session ID. The real fix, requiring authentication of client when performing these changes to the session. Discussion need to determine what required security protection that are needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853178&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 02:16:09 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-853184 ] How to learn servers multicast capabilities Bugs item #853184, was opened at 2003-12-03 11:16 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=853184&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: How to learn servers multicast capabilities Initial Comment: If a media session is delivered through the usage of multicast, the session description, to indicate that delviery will be done to assigned multicast address. So this is evident as long as you can put the multicast address into the SDP and distribute it. However how does a client learn that a session can be distributed as multicast, but no multicast address is pre-assigned to the session when the SDP is published? It seems that we can't quite express this case. Or does someone see a possiblity? Is it something that needs to be solved. Another interesting use case is if a multicast conference invites a RTSP server into the session and the controlling entity request the server to play to the already used multicast addresses. Does the server needs to be able to announce this support, or is it something the client simply ask for and the server either succeds or fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=853184&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 10:28:23 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-533691 ] Clarify Range Where t0 <= t1 Bugs item #533691, was opened at 2002-03-22 09:36 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Aravind Narasimhan (arvy_n) Summary: Clarify Range Where t0 <= t1 Initial Comment: If the server receives a PLAY range from t0-t1, where t0 < t1, should it reject the PLAY, or should the server play backwards as if the timescale is -1? If t0 = t1, should the server send any media data after responding 200 OK? We've seen different servers behave differently in this scenario. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-12-03 10:28 Message: Logged In: NO you should put pictures of scale bugs on this site, the life cycle of the bugs, the breeding season of them, the geographic location, visual evidence of the damage the pests can do, the names of the plants or crops that the bugs go after, pesticides that can be used to kill the bugs, info about how to safely apply the pesticide, the dangers of the pesticide to the environment, and suggestions for ways to control the pest beside pesticides. ---------------------------------------------------------------------- Comment By: Aravind Narasimhan (arvy_n) Date: 2003-10-01 08:16 Message: Logged In: YES user_id=437699 The following text has been added to the spec with regards to this bug: By default, range intervals increase, where the second point is larger than the first point. Example: Range: npt=10-15 However, range intervals can also decrease if the Scale header (see section 13.34) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired. Example: Scale: -1 Range: npt=15-10 Decreasing ranges are still half open intervals as described above. Thus, For range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback. Example: Scale: -1 Range: npt=15-0 In this range both 15 and 0 are closed. A decreasing range interval without a corresponding negative Scale header is not valid. ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2003-03-05 09:53 Message: Logged In: YES user_id=20397 If scale positive, t1 must >= t0. Otherwise, t1 must <= t0 ---------------------------------------------------------------------- Comment By: Thomas M Zeng (zengtm) Date: 2002-03-22 09:41 Message: Logged In: YES user_id=20397 I just came across 513880, which is closely related. That is to say, if timescale is positive, should the play range to be required to have t1 > t0? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=533691&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: "SourceForge.net" Date: Wed, 03 Dec 2003 10:30:03 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-493265 ] Pause - Play behaviour clarification Bugs item #493265, was opened at 2001-12-14 03:55 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194 Category: None Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Magnus Westerlund (magwes) Summary: Pause - Play behaviour clarification Initial Comment: The scenario is the following: A media stream is ready to start playing when the client does the following A-C A: PLAY range npt:10-30 B: @npt:22-> PAUSE C: PLAY (no range) This will result in resuming playing at npt:22. The unclearity is which of the following behaviour is the correct one? 1. Play until 30, i.e the second play is equal to PLAY range:22-30. 2. Play until end of media, i.e. the second play is equal to PLAY range:22- The RFC states the following in Section 10.6 third paragraph: "A PAUSE request discards all queued PLAY requests. However, the pause point in the media stream MUST be maintained. A subsequent PLAY request without Range header resumes from the pause point." The main unclarity is in what resumes means when also taking the first sentence into account. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-12-03 10:30 Message: Logged In: NO make the website more interesting and easier to understand, you'll get a lot more visitors ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2003-10-23 07:29 Message: Logged In: YES user_id=302620 This comment has been addressed by the general clarification of PLAY and PAUSE handling plus some furhter clarificiations. The specification text indicates that unless the second play request specify a range the server will play from the pause point of 22 second until the end of media. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-17 12:32 Message: Logged In: YES user_id=3796 I would be inclined toward the 22-end interpretation (your option 2). Won't change the spec until it's been covered by the group, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=377744&aid=493265&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 4 15:39:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13427 for ; Thu, 4 Dec 2003 15:39:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0Fc-0007q6-1z for mmusic-archive@odin.ietf.org; Thu, 04 Dec 2003 15:39:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Kd4cB030130 for mmusic-archive@odin.ietf.org; Thu, 4 Dec 2003 15:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0Fb-0007pt-VF for mmusic-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 15:39:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13409 for ; Thu, 4 Dec 2003 15:38:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS0Fa-0007nA-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:39:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS0Fa-0007n6-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0FY-0007pM-Gd; Thu, 04 Dec 2003 15:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0F4-0007p0-Ga for mmusic@optimus.ietf.org; Thu, 04 Dec 2003 15:38:30 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13294; Thu, 4 Dec 2003 15:37:52 -0500 (EST) Message-Id: <200312042037.PAA13294@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: mmusic@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 04 Dec 2003 15:37:52 -0500 Subject: [MMUSIC] I-D ACTION:draft-srikantan-mmusic-rtsp-streaming-relay-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Streaming Relays Author(s) : G. Srikantan Filename : draft-srikantan-mmusic-rtsp-streaming-relay-00.txt Pages : 0 Date : 2003-12-4 Delivery of streaming media to a large number of clients distributed across several geographic and network boundaries presents several challenges in terms of scalability and stream quality. This document describes N-tier relays to address scalability and quality issues in the delivery of stored and live content. This document addresses issues in stream synchronization, content announcement/expiry, reliability of transport, failover/recovery, administration, and security issues. This document propose a set of primitives to enable implementation of Push and Pull mechanisms for N-tier relays. We also provide usage scenarios where each approach is most useful. The Pull and Push mechanisms are complementary and provide valuable building blocks in N-tier relays. This document introduces a few new RTSP methods and headers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-srikantan-mmusic-rtsp-streaming-relay-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154539.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-srikantan-mmusic-rtsp-streaming-relay-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154539.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 4 15:41:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13620 for ; Thu, 4 Dec 2003 15:41:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0HY-000827-Lk for mmusic-archive@odin.ietf.org; Thu, 04 Dec 2003 15:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4Kf4uF030873 for mmusic-archive@odin.ietf.org; Thu, 4 Dec 2003 15:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0HY-00081s-C3 for mmusic-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 15:41: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 PAA13598 for ; Thu, 4 Dec 2003 15:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS0HW-00000o-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:41:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS0HW-00000l-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:41:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0HX-000807-Cn; Thu, 04 Dec 2003 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0Gg-0007wd-QF for mmusic@optimus.ietf.org; Thu, 04 Dec 2003 15:40:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13515; Thu, 4 Dec 2003 15:39:54 -0500 (EST) Message-Id: <200312042039.PAA13515@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 04 Dec 2003 15:39:54 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-req-01.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --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 Filename : draft-ietf-mmusic-img-req-01.txt Pages : 16 Date : 2003-12-4 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-req-01.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-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154904.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-req-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-req-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154904.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 4 15:41:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13640 for ; Thu, 4 Dec 2003 15:41: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 1AS0Hj-000869-Cn for mmusic-archive@odin.ietf.org; Thu, 04 Dec 2003 15:41:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4KfFAr031123 for mmusic-archive@odin.ietf.org; Thu, 4 Dec 2003 15:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0Hj-00085u-9G for mmusic-web-archive@optimus.ietf.org; Thu, 04 Dec 2003 15:41:15 -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 PAA13595 for ; Thu, 4 Dec 2003 15:40:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AS0HV-00000i-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:41:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AS0HV-00000f-00 for mmusic-web-archive@ietf.org; Thu, 04 Dec 2003 15:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0HV-0007xx-St; Thu, 04 Dec 2003 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AS0Gb-0007wE-DA for mmusic@optimus.ietf.org; Thu, 04 Dec 2003 15:40:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13487; Thu, 4 Dec 2003 15:39:48 -0500 (EST) Message-Id: <200312042039.PAA13487@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 04 Dec 2003 15:39:48 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-01.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , --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) : Y. Nomura Filename : draft-ietf-mmusic-img-framework-01.txt Pages : 27 Date : 2003-12-4 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 several use case scenarios requirering the IMG framework, 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-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-framework-01.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-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-4154855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-4154855.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 5 07:43:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03183 for ; Fri, 5 Dec 2003 07:43: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 1ASFIW-0002cS-KI for mmusic-archive@odin.ietf.org; Fri, 05 Dec 2003 07:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB5Ch4Ra010062 for mmusic-archive@odin.ietf.org; Fri, 5 Dec 2003 07:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASFIW-0002cD-G8 for mmusic-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 07:43: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 HAA03174 for ; Fri, 5 Dec 2003 07:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASFIV-0000WS-00 for mmusic-web-archive@ietf.org; Fri, 05 Dec 2003 07:43:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASFIV-0000WP-00 for mmusic-web-archive@ietf.org; Fri, 05 Dec 2003 07:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASFIS-0002be-U4; Fri, 05 Dec 2003 07:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASFHs-0002bG-BQ for mmusic@optimus.ietf.org; Fri, 05 Dec 2003 07:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03171 for ; Fri, 5 Dec 2003 07:42:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASFHr-0000WC-00 for mmusic@ietf.org; Fri, 05 Dec 2003 07:42:23 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ASFHq-0000W9-00 for mmusic@ietf.org; Fri, 05 Dec 2003 07:42:23 -0500 Received: from esealnt611.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB5CgLI2010785 for ; Fri, 5 Dec 2003 13:42:21 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW9ADMNH; Fri, 5 Dec 2003 13:42:53 +0100 Message-ID: <3FD07D2C.3080406@ericsson.com> Date: Fri, 05 Dec 2003 13:42:20 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP Telecon 031203 Minutes of meeting Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Here is the minutes of meeting from Wednesday's telecon. I hope more people will be able to participate on the next meeting. Cheers Magnus RTSP telecon minutes 031203 Participants ------------ Magnus Westerlund Sean Sheedy Colin Perkins Geetha Srikantan 1. Opening of meeting and Administrative Magnus Westerlund will produce minutes. 2. RTSP Core 2.1 Core specification bugs under developement. a. http://rtsp.org/bug507882 - RTP timestamp and pause - Aravind has not yet produced any text, but has promised to do it shortly. b. http://rtsp.org/bug742328 - How to handle PLAY request when at the end of a media clip - We will close this, as no comments has been received. c. http://rtsp.org/bug742348 - Usage of implicit REDIRECT. - Arawind will write up text. d. http://rtsp.org/bug640272 - Default way of deriving aggregate URL - Magnus will edit this in. e. http://rtsp.org/bug771638 - a=range in SDP to indicate live media - Check if live is written, and try to remove, in benefit for Unbounded session. - Check if the syntax does not create greate clashes with the TiVo use case. However it is unlikely that the full semantics neceassary can be expresed with current attributes. f. http://rtsp.org/bug531189 - How does REDIRECT method work - Conclusion from Minneapolis needs to be edited in: Server MAY drop the connection after it has recieved 200 OK response on a REDIRECT. Needs to be edited in. g. http://rtsp.org/bug770522 - Request to response time is not limited. - Sean will update the proposal and post to the mailing list. h. http://rtsp.org/bug795295 - TEARDOWN using * and the Ready-nm state - This item will be closed. i. http://rtsp.org/bug804219 - How to handle sync in re-SETUP - In certain cases the move may result in a totally new RTP session, therefore all new synchronization information may be required. Check if language is strict enough, and if necessary clarify between cases where mapping can be maintained and where needs to be changed. j. http://rtsp.org/bug806404 - Re-SETUP of transport parameters - It seems initial and ready state changes are equal, and the play state being more restricted. - Point out that in the general case the changes can result in that a new RTP session is created. - Another consideration is for connection oriented media, can a switch over be performed relatively seamless. - It seems that not requiring a PAUSE, SETUP, PLAY sequence makes sense, thus motivating the continuation of this work. - However the proposals and text needs more thought. - Geetha will provide new text. k. http://rtsp.org/bug810666 - Removal of SETUP in play state - Magnus will edit in that it is unspecified. l. http://rtsp.org/bug811815 - Use of c= in SDP to know possible address classes - Needs to look into backwards compatibility issues. - This issue is connected to issue (r), to allow a server to announce dual address realm support. - It needs a proposal text for evaluation. m. http://rtsp.org/bug795314 - Caching of OPTIONS request - Magnus will look into if the current caching text is complete enough, if not it will be declared unspecified. n. http://rtsp.org/bug850256 - When must RTP-Info be included? - Usage of RTP-Info can be a SHOULD, however if the server does not provide it, the client will be required to do synchronization by RTCP. Servers are strongly recommened if able to include RTP-Info with timestamp information. o. http://rtsp.org/bug850265 - Removed features are unspecified, not forbidden - Needs to be edited in. p. http://rtsp.org/bug840304 - CSEQ is direction dependent in numberspaces. - Nothing done, needs to be edited in. q. http://rtsp.org/bug850267 - Should all ABNF syntax be gathered in one chapter? - Nothing done, needs to be edited in. r. http://rtsp.org/bug829528 - Usage of Grouping of media lines with RTSP. - For futher study and discussion. s. http://rtsp.org/bug853175 - Dest_addr needs indicator for using RTSP IP - For futher study and discussion. t. http://rtsp.org/bug853178 - Security risk with changing transport parameters - For futher study and discussion. u. http://rtsp.org/bug853184 - How to learn servers multicast capabilities - For futher study and discussion. 2.2 Tracking of items not require actions currently. - Nothing to discuss here 3. RTSP Specifiction Extensions 3.1 Streaming Relays. We had some discussions about this. Geetha wil publish the proposal as a draft. Needs to be reviewed by a larger group. 3.2 End of Media - Skiped 3.3 RTSP and NAT issues - Skiped 4. Next meeting - Will be in mid January 5. Meeting closed. -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 5 20:37:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06316 for ; Fri, 5 Dec 2003 20:37:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASRNb-00067z-3L for mmusic-archive@odin.ietf.org; Fri, 05 Dec 2003 20:37:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB61b7Vq023548 for mmusic-archive@odin.ietf.org; Fri, 5 Dec 2003 20:37:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASRNa-00067h-Pp for mmusic-web-archive@optimus.ietf.org; Fri, 05 Dec 2003 20:37: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 UAA06309 for ; Fri, 5 Dec 2003 20:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASRNY-0005qE-00 for mmusic-web-archive@ietf.org; Fri, 05 Dec 2003 20:37:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASRNY-0005qA-00 for mmusic-web-archive@ietf.org; Fri, 05 Dec 2003 20:37:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASRNV-00065W-Aj; Fri, 05 Dec 2003 20:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASRMZ-00064U-3d for mmusic@optimus.ietf.org; Fri, 05 Dec 2003 20:36: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 UAA06275 for ; Fri, 5 Dec 2003 20:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASRMW-0005pC-00 for mmusic@ietf.org; Fri, 05 Dec 2003 20:36:00 -0500 Received: from mail4.microsoft.com ([131.107.3.122]) by ietf-mx with esmtp (Exim 4.12) id 1ASRMV-0005oa-00 for mmusic@ietf.org; Fri, 05 Dec 2003 20:36:00 -0500 Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 17:35:35 -0800 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Dec 2003 17:35:29 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Dec 2003 17:34:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Draft MMUSIC Minutes Date: Fri, 5 Dec 2003 17:35:27 -0800 Message-ID: Thread-Topic: [MMUSIC] Draft MMUSIC Minutes Thread-Index: AcO5w00RL3JT3uHsTCCq4awupuaJAwB085rQ From: "Orit Levin" To: "Flemming Andreasen" Cc: "Joerg Ott" , , X-OriginalArrivalTime: 06 Dec 2003 01:34:24.0449 (UTC) FILETIME=[147AD310:01C3BB99] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I see your points. I just can say that: 1. It is really sad that none of us have time (including myself) to specify this behavior in the upcoming standard. 2. Just "disallowing" it will not help! Implementers that are not interested in the "mid" benefits will not read through all the possible cases of the "mid" use and find out that it is actually "is allowed" and can happen more often as the industry moves forward!!! The basic SDP needs to specify how you act upon receiving this case. Orit. -----Original Message----- From: Flemming Andreasen [mailto:fandreas@cisco.com]=20 Sent: Wednesday, December 03, 2003 8:41 AM To: Orit Levin Cc: Joerg Ott; mmusic@ietf.org; csp@csperkins.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes Orit Levin wrote: > Unfortunately, I couldn't participate in the last MMUSIC meeting. > Reading the minutes, I found this one peculiar: > ------------------ > * Semantics are undefined for multiple "m=3D" lines with the same port > and "c=3D" The interpretation should go into the SDP-new draft as a > clarification. There are minor implications on the offer-answer > examples. Gonzalo Camarillo > sent some text, but for a different case (hierarchical > encoding). Flemming Andreasen proposed > that we simply prohibit this construct. The meeting agreed to the > prohibition. > ------------------- > > I am wondering how can you allow for one particular application and prohibit all the others? We need to make it well-defined one way or the other. We had a thread on this issue titled "Multiple 'm' lines with the same port number" at the end of April 2003, where the general consensus seemed to be in-line with the above. The problem I have with the interpretation saying that you *can* have multiple "m=3D" lines with the same address and port is that = it raises all kinds of issues that have not been dealt with. For example: - Can I use different top-level MIME media types and/or transports for these "m=3D" lines ? - How does offer/answer deal with them ? Present text suggests that an "m=3D" line corresponds to a media stream, however this suggests = something different. - What about media stream parameters applied to one of these "m=3D" = lines, but not the other, or applied inconsistently ? For example, what if I set one of them to "inactive" and the other to "sendrecv", specify one SRTP key for of them, and another for the other, etc. What am I allowed to do, what not, and what do I do if it is violated ? The list goes on. In short, there is lot of issues that would need to be dealt with before this would be well-defined and interoperable, and that suggests strongly that it either was not implied by the original spec (which the above referenced thread seemed to converge on) or was not very well thought out. The end result is the same; I would not expect old implementations to understand these semantics in any kind of interoperable way and hence it should not be part of the updated spec either (new functionality). > > For the existing implementations, that don't understand the fid attribute and the associated grouping, it will appear exactly as the same case. > That is different. Fid is an extension, not part of the core SDP spec. Also, fid has specified ways of recognizing and recovering from answerers that to does not support the extension. -- Flemming > > Orit. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Dec 7 05:31:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19652 for ; Sun, 7 Dec 2003 05:31:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASwBq-0007nu-S2 for mmusic-archive@odin.ietf.org; Sun, 07 Dec 2003 05:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7AV2sX029992 for mmusic-archive@odin.ietf.org; Sun, 7 Dec 2003 05:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASwBq-0007nf-NU for mmusic-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 05:31: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 FAA19629 for ; Sun, 7 Dec 2003 05:30:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASwBn-00076J-00 for mmusic-web-archive@ietf.org; Sun, 07 Dec 2003 05:30:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASwBm-00076G-00 for mmusic-web-archive@ietf.org; Sun, 07 Dec 2003 05:30:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASwBp-0007mx-88; Sun, 07 Dec 2003 05:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASwBK-0007mE-28 for mmusic@optimus.ietf.org; Sun, 07 Dec 2003 05:30: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 FAA19613 for ; Sun, 7 Dec 2003 05:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASwBG-00075y-00 for mmusic@ietf.org; Sun, 07 Dec 2003 05:30:26 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ASwBG-00075R-00 for mmusic@ietf.org; Sun, 07 Dec 2003 05:30:26 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61292 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ASwAf-00011j-00; Sun, 07 Dec 2003 10:29:49 +0000 Date: Sun, 7 Dec 2003 10:29:49 +0000 From: Colin Perkins To: "Orit Levin" Cc: fandreas@cisco.com, jo@tzi.uni-bremen.de, mmusic@ietf.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes Message-Id: <20031207102949.2003cab0.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> "Orit Levin" writes: > I see your points. I just can say that: > > 1. It is really sad that none of us have time (including myself) to > specify this behavior in the upcoming standard. > 2. Just "disallowing" it will not help! Implementers that are not > interested in the "mid" benefits will not read through all the possible > cases of the "mid" use and find out that it is actually "is allowed" and > can happen more often as the industry moves forward!!! > > The basic SDP needs to specify how you act upon receiving this case. If changes are needed in SDP-new, please suggest text. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Dec 7 09:03:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23636 for ; Sun, 7 Dec 2003 09:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzV3-0004uA-5D for mmusic-archive@odin.ietf.org; Sun, 07 Dec 2003 09:03:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB7E35jd018855 for mmusic-archive@odin.ietf.org; Sun, 7 Dec 2003 09:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzV3-0004u2-0A for mmusic-web-archive@optimus.ietf.org; Sun, 07 Dec 2003 09:03: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 JAA23633 for ; Sun, 7 Dec 2003 09:02:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASzV1-0001Jl-00 for mmusic-web-archive@ietf.org; Sun, 07 Dec 2003 09:03:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASzV1-0001Ji-00 for mmusic-web-archive@ietf.org; Sun, 07 Dec 2003 09:03:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzUy-0004tU-RR; Sun, 07 Dec 2003 09:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASzUt-0004tB-99 for mmusic@optimus.ietf.org; Sun, 07 Dec 2003 09:02:55 -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 JAA23630 for ; Sun, 7 Dec 2003 09:02:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASzUr-0001Jf-00 for mmusic@ietf.org; Sun, 07 Dec 2003 09:02:53 -0500 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1ASzUr-0001Ja-00 for mmusic@ietf.org; Sun, 07 Dec 2003 09:02:53 -0500 Received: from eamrcnt750.exu.ericsson.se (eamrcnt750.exu.ericsson.se [138.85.133.51]) by imr1.ericy.com (8.12.10/8.12.10) with ESMTP id hB7E2DWm014135; Sun, 7 Dec 2003 08:02:13 -0600 (CST) Received: from ericsson.com (rvi2-92-126.sw.ericsson.se [153.88.92.126]) by eamrcnt750.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id YGLQAKSW; Sun, 7 Dec 2003 08:02:07 -0600 Message-ID: <3FD332E2.60506@ericsson.com> Date: Sun, 07 Dec 2003 16:02:10 +0200 X-Sybari-Trust: ea46f1c5 6fa56f4d 884b220c 00000138 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin CC: Flemming Andreasen , Joerg Ott , mmusic@ietf.org, csp@csperkins.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Orit, > 1. It is really sad that none of us have time (including myself) to > specify this behavior in the upcoming standard. The idea is not to add new functionality to SDPnew. The idea is to clarify existing functionality and fix known bugs. Multiples m lines with the same transport address (IP address plus port) were never allowed, and that is what SDPnew is going to clarify. > 2. Just "disallowing" it will not help! Implementers that are not > interested in the "mid" benefits will not read through all the possible > cases of the "mid" use and find out that it is actually "is allowed" and > can happen more often as the industry moves forward!!! > > The basic SDP needs to specify how you act upon receiving this case. You will never receive an SDP with multiple m lines with the same transport address. Existing implementations don't do it, and future implementations will not do it either. Regarding the grouping framework, it does not allow multiple m lines with the same transport address either. So, implementors do not need to read thru those specs either. This issue has nothing to do with the grouping framework. Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 8 14:51:19 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26740 for ; Mon, 8 Dec 2003 14:51:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRPN-0001nI-IT for mmusic-archive@odin.ietf.org; Mon, 08 Dec 2003 14:51:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB8Jp5xC006890 for mmusic-archive@odin.ietf.org; Mon, 8 Dec 2003 14:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRPN-0001n3-Ds for mmusic-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 14:51:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26698 for ; Mon, 8 Dec 2003 14:50:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATRPK-0003c7-00 for mmusic-web-archive@ietf.org; Mon, 08 Dec 2003 14:51:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATRPJ-0003c3-00 for mmusic-web-archive@ietf.org; Mon, 08 Dec 2003 14:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATRPJ-0001lT-6S; Mon, 08 Dec 2003 14:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATROp-0001ka-17 for mmusic@optimus.ietf.org; Mon, 08 Dec 2003 14:50:31 -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 OAA26660 for ; Mon, 8 Dec 2003 14:50:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATROm-0003be-00 for mmusic@ietf.org; Mon, 08 Dec 2003 14:50:28 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx with esmtp (Exim 4.12) id 1ATROl-0003bQ-00 for mmusic@ietf.org; Mon, 08 Dec 2003 14:50:27 -0500 Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Mon, 8 Dec 2003 11:49:34 -0800 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 8 Dec 2003 11:49:18 -0800 Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Dec 2003 11:50:06 -0800 Received: from RED-MSG-52.redmond.corp.microsoft.com ([157.54.12.12]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 8 Dec 2003 11:49:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MMUSIC] Draft MMUSIC Minutes Date: Mon, 8 Dec 2003 11:49:51 -0800 Message-ID: Thread-Topic: [MMUSIC] Draft MMUSIC Minutes Thread-Index: AcO8ys+DHUq/G/FeQReM53PF8Tj8KgA+TGeQ From: "Orit Levin" To: "Gonzalo Camarillo" Cc: "Flemming Andreasen" , "Joerg Ott" , , X-OriginalArrivalTime: 08 Dec 2003 19:49:19.0668 (UTC) FILETIME=[5EB53740:01C3BDC4] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable You are right. I reread the RFC 3388 and it explicitly disallows this case. Sorry for the confusion, Orit.=20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Sunday, December 07, 2003 6:02 AM To: Orit Levin Cc: Flemming Andreasen; Joerg Ott; mmusic@ietf.org; csp@csperkins.org Subject: Re: [MMUSIC] Draft MMUSIC Minutes Orit, > 1. It is really sad that none of us have time (including myself) to=20 > specify this behavior in the upcoming standard. The idea is not to add new functionality to SDPnew. The idea is to clarify existing functionality and fix known bugs. Multiples m lines with the same transport address (IP address plus port) were never allowed, and that is what SDPnew is going to clarify. > 2. Just "disallowing" it will not help! Implementers that are not=20 > interested in the "mid" benefits will not read through all the=20 > possible cases of the "mid" use and find out that it is actually "is=20 > allowed" and can happen more often as the industry moves forward!!! >=20 > The basic SDP needs to specify how you act upon receiving this case. You will never receive an SDP with multiple m lines with the same transport address. Existing implementations don't do it, and future implementations will not do it either. Regarding the grouping framework, it does not allow multiple m lines with the same transport address either. So, implementors do not need to read thru those specs either. This issue has nothing to do with the grouping framework. Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 8 19:56:20 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16712 for ; Mon, 8 Dec 2003 19:56: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 1ATWAV-00073B-Kw for mmusic-archive@odin.ietf.org; Mon, 08 Dec 2003 19:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB90u3l4027097 for mmusic-archive@odin.ietf.org; Mon, 8 Dec 2003 19:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWAV-00072y-HZ for mmusic-web-archive@optimus.ietf.org; Mon, 08 Dec 2003 19:56: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 TAA16687 for ; Mon, 8 Dec 2003 19:55:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWAT-0003Ly-00 for mmusic-web-archive@ietf.org; Mon, 08 Dec 2003 19:56:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATWAT-0003Lv-00 for mmusic-web-archive@ietf.org; Mon, 08 Dec 2003 19:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWAT-00072H-IG; Mon, 08 Dec 2003 19:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATWAM-00071w-TS for mmusic@optimus.ietf.org; Mon, 08 Dec 2003 19:55:55 -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 TAA16684; Mon, 8 Dec 2003 19:55:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATWAK-0003Ls-00; Mon, 08 Dec 2003 19:55:52 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1ATWAK-0003LV-00; Mon, 08 Dec 2003 19:55:52 -0500 Received: from chiimc01.npac.com (chiimc01.neustar.com [10.32.90.4]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hB90seb9030155; Tue, 9 Dec 2003 00:54:40 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Dec 2003 18:54:45 -0600 Message-ID: From: "Peterson, Jon" To: "'Mark Baugher'" , Kumiko Ono Cc: mary.barnes@nortelnetworks.com, tachimoto.shinya@lab.ntt.co.jp, sipping@ietf.org, mmusic@ietf.org, cyrus@ntt-at.com, fandreas@cisco.com, dwing@cisco.com Subject: RE: [MMUSIC] Re: e2m, m2m security drafts Date: Mon, 8 Dec 2003 18:54:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , A couple of notes on all this. > Thanks. One more clarification, please. By "encrypted data" (which in > my case is the SDP crypto attribute that carries keying material and > parameters), do you mean the entire SDP message or can it be restricted > to selected lines of the SDP message? Will it be possible to share > all needed information in the SDP message *except* the security > descriptions attribute in the SDP message? Today, we don't really have a way in SIP to encrypt only part of an SDP message - a requirement for partial encryption has never really been fully articulated or understood. I imagine that any such requirement would be satisfied by splitting an SDP body into different MIME components to which separate security properties would be applied. I understand why you'd think that sdescriptions should be end-to-end, since they are only for the consumption of endpoints that aspire to use sRTP, or something similar. But I'm not sure that we should grant keying material for sRTP a specific exemption from the principles underlying the e2m work. Unfortunately, I suspect that operators are as likely to want a degree of control over the use of e2e media encryption as they are to want to munge anything else in SDP. [snip] > > It is also possible that an X.509 PKI > is found to be not the most deployable solution for global > telephony. Hence, my point about accommodating different > structures in the future. Today, there are S/MIME and PGP MIME. I doubt that PGP MIME is any more 'deployable' than PKI, unfortunately. The original version of the SIP standard (RFC2543) contained some PGP-related text, and it was not included in subsequent revisions for a number of reasons. But certainly it's very unlikely that we'll get any closer to interoperable end-to-end security by introducing more alternatives for e2e security in SIP. Giving implementers a choice between S/MIME and PGP MIME is, in fact, guaranteed to get us farther from our goal. It is also important to note that support for S/MIME does not directly entail the use of X.509. There are a number of specifications (notably RFC3211) that define symmetric key schemes usable by S/MIME in place of X.509. Self-signed certificates are also meaningful for S/MIME - in fact, there's a great deal of text in RFC3261 (notably in Section 23.1/23.2) dedicated to exchanging self-signed certs. > A core specification would enable one to apply what you develop > for one security specification (S/MIME) to others (PGP MIME, etc). > To do this would require one to take out the features of the > e2m and m2m security that are general to all secure multipart > specifications, put these features into one document and then put > the features that are specific to S/MIME in a second document. I agree that the e2m work is not the right place to explore whether or not we should introduce new options for e2e security in SIP. That is a core SIP issue, and not something that should be considered solely in light of the e2m requirements. That much said, I do not advocate reopening the underlying principles of MIME security for SIP. I think the e2m work should focus on the existing security mechanisms that have been established for SIP in RFC3261, and should not complicate itself by creating modularities that depend on the (speculative) use of other MIME security systems. Jon Peterson NeuStar, Inc. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 9 05:55:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21737 for ; Tue, 9 Dec 2003 05:55:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATfWH-0008PX-Bz for mmusic-archive@odin.ietf.org; Tue, 09 Dec 2003 05:55:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9At9Em032325 for mmusic-archive@odin.ietf.org; Tue, 9 Dec 2003 05:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATfWG-0008PI-UI for mmusic-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 05:55:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21728 for ; Tue, 9 Dec 2003 05:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATfWD-0005RP-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 05:55:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATfWC-0005RM-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 05:55:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATfWA-0008OY-En; Tue, 09 Dec 2003 05:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATfVZ-0008O3-QX for mmusic@optimus.ietf.org; Tue, 09 Dec 2003 05:54:25 -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 FAA21725 for ; Tue, 9 Dec 2003 05:54:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATfVV-0005RH-00 for mmusic@ietf.org; Tue, 09 Dec 2003 05:54:21 -0500 Received: from mail.com.dtu.dk ([192.38.68.3] helo=com.dtu.dk) by ietf-mx with esmtp (Exim 4.12) id 1ATfVV-0005Qy-00 for mmusic@ietf.org; Tue, 09 Dec 2003 05:54:21 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Tue, 9 Dec 2003 11:53:52 +0100 Message-ID: Thread-Topic: Fractions of seconds in NPT in RTSP thread-index: AcO+Qruj7mrwiUyeS5WenC5AS7V/Iw== From: "Philip Grove" To: Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Fractions of seconds in NPT in RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable In section 3.6 "Normal Play Time" of RFC 2326 in the grammar for npt-range you can find this line: npt-hhmmss =3D npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] Likewise this line can be found in section 3.5 of draft-ietf-mmusic-rfc2326bis-05.txt. What bothers me is the part that says [ "." *DIGIT ]. I don't really under stand the point in allowing zero digits in the optional fraction part of NPT. The same can be seen in the grammar for npt-sec in the line above in both documents. I would think that writing [ "." 1*DIGIT ] would make more sense, or if there is a reason making it more clear. Philip Grove _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 9 07:08:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23510 for ; Tue, 9 Dec 2003 07:08: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 1ATgeq-0002yX-Vy for mmusic-archive@odin.ietf.org; Tue, 09 Dec 2003 07:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9C84Wg011438 for mmusic-archive@odin.ietf.org; Tue, 9 Dec 2003 07:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATgeq-0002yJ-Po for mmusic-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 07:08: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 HAA23506 for ; Tue, 9 Dec 2003 07:07:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATgem-0006H6-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 07:08:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATgel-0006H3-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 07:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATgen-0002wY-Dk; Tue, 09 Dec 2003 07:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATgeZ-0002sk-BB for mmusic@optimus.ietf.org; Tue, 09 Dec 2003 07:07:47 -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 HAA23495 for ; Tue, 9 Dec 2003 07:07:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATgeU-0006Gr-00 for mmusic@ietf.org; Tue, 09 Dec 2003 07:07:42 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1ATgeU-0006Go-00 for mmusic@ietf.org; Tue, 09 Dec 2003 07:07:42 -0500 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hB9C7dI2005780; Tue, 9 Dec 2003 13:07:39 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW6Z25RD; Tue, 9 Dec 2003 13:08:24 +0100 Message-ID: <3FD5BB0B.3030005@ericsson.com> Date: Tue, 09 Dec 2003 13:07:39 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Philip Grove CC: mmusic@ietf.org Subject: Re: [MMUSIC] Fractions of seconds in NPT in RTSP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Philip, We have discussed this grammar. I understand and agree that if we were specifying RTSP for the first time, I would definitely vote for changing it. However today I would not like to change it as it would change what is allowed by the grammar. Thus having this change has impact on backwards compatibility. Cheers Magnus Philip Grove wrote: > In section 3.6 "Normal Play Time" of RFC 2326 in the grammar for > npt-range you can find this line: > npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] > > Likewise this line can be found in section 3.5 of > draft-ietf-mmusic-rfc2326bis-05.txt. > > What bothers me is the part that says [ "." *DIGIT ]. I don't really > under stand the point in allowing zero digits in the optional fraction > part of NPT. The same can be seen in the grammar for npt-sec in the line > above in both documents. I would think that writing [ "." 1*DIGIT ] > would make more sense, or if there is a reason making it more clear. > > Philip Grove > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > -- Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 9 17:21:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20442 for ; Tue, 9 Dec 2003 17:21:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATqE4-00051I-K5 for mmusic-archive@odin.ietf.org; Tue, 09 Dec 2003 17:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB9ML4qR019295 for mmusic-archive@odin.ietf.org; Tue, 9 Dec 2003 17:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATqE4-000518-6k for mmusic-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 17:21: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 RAA20421 for ; Tue, 9 Dec 2003 17:20:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATqE1-0002HP-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 17:21:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATqE1-0002HL-00 for mmusic-web-archive@ietf.org; Tue, 09 Dec 2003 17:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATqE2-00050c-2A; Tue, 09 Dec 2003 17:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASyap-0003XP-UT for mmusic@optimus.ietf.org; Sun, 07 Dec 2003 08:04: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 IAA22782; Sun, 7 Dec 2003 08:04:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASyao-0000qC-00; Sun, 07 Dec 2003 08:04:58 -0500 Received: from orion.lrg.ufsc.br ([150.162.63.1] helo=lrg.ufsc.br) by ietf-mx with esmtp (Exim 4.12) id 1ASyan-0000q8-00; Sun, 07 Dec 2003 08:04:57 -0500 Received: from localhost (westphal@localhost) by (8.9.3+Sun/8.9.3) with ESMTP id LAA26270 Date: Sun, 7 Dec 2003 11:04:09 -0400 (WST) From: Carlos Becker Westphall To: Undisclosed recipients: ; Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: [MMUSIC] 9th Brazilian Workshop on Network & Services Operations & Management Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE * Apologies if you receive multiple copies of this announcement * WGRS - Workshop on Network & Services Operations & Management The 9th Brazilian Workshop on Network & Services Operations & Management (WGRS'2004) is an annual event that has been held since 1995. Previously known as WTMN (Workshop on Telecommunication Networks & Services Management), the event has been held either with the Brazilian Symposium on Computer Networks (SBRC) or with the Latin American Network Operations and Management Symposium (LANOMS). The main goal of WGRS is to provide a Brazilian forum in the area of network management focused on the local audience, involving networking and telecommunication companies, academic institutions, service providers and equipment vendors.=20 This year, in its 9th edition, WGRS will take place in Gramado - Rio Grande do Sul, during the 22th SBRC . Besides the presentation of papers describing research results, on-going projects and practical experience reports, a number of invited keynotes from the industry is also planned. Topics of interest include, but are not limited to: * Integrating Intrusion Detection and Network Management * Intrusion Policy Management * Web Services Security * Mobile/Wireless Network Management * Business and Service Management * Management Platforms, Interoperability, Standards and Protocols * Management of Networks and Services: VPNs, Optical Networks, CATV Networks, Mobile and Ad-Hoc Networks, Voice over IP, Transaction- Oriented Services, Electronic Commerce, Active and Programmable Networks, Sensor Networks * Management Technologies and Frameworks (Web, XML, CORBA, DEN, etc) * Management Aspects of Service Pricing, Accounting and Billing * Management of Service Level Agreements and Quality of Service * Data Warehousing and Data Mining in Management * Programmable, Mobile and Intelligent Agents in Management * Network and Systems Monitoring * Fault and Performance Management * Security Management * Configuration Management and Policy-Driven Management * Information Modeling * Traffic and Performance Management * Open-Source Management Software * Management of Grid Computing, Clusters, Peer-to-Peer Applications, and Ubiquitous Computing Environments * Operations Support Systems * Business Processes for Network and Service Management * Peer-to-peer Network Technologies for Management * Management of Distributed Systems * Case Studies and Experiences in Management Paper Submission Submitted manuscripts must be written in either English, Spanish or Portuguese and the text should not exceed 8 pages, including the abstract, figures, diagrams, references, etc (very small figures, as well as bitmap format should be avoided). The page format should be A4 (29.7 x 21.0 cm), font size 12 pts, Times, lateral margins 2.5 cm, upper margin 3.0 cm, lower margin 2.5 cm, with 12pt Times fonts, single column page with no more than 45 lines. The paper can be prepared using one of the templates avaliable in the SBC webpage (http://www.sbc.org.br). The paper must be submitted eletronically through EDAS (at http://soyuz.metropoa.tche.br/sbrc2004_wgrs). The file must be necessarily in the postscript format (use generic postscript) or PDF (Portable Document Format).

Program Committee * Ant=F4nio A. F. Loureiro (UFMG) loureiro@dcc.ufmg.br * Bruno Schulze (LNCC) schulze@lncc.br * Carlos B. Westphall (UFSC) westphal@lrg.ufsc.br * Carlos de Castro Goulart (UFV) goulart@dpi.ufv.br * Edmundo R. M. Madeira (UNICAMP) edmundo@ic.unicamp.br * Elias P. Duarte Jr. (UFPR) elias@inf.ufpr.br=20 * Elizabeth S. Specialski (UFSC) beth@inf.ufsc.br * Iara Machado (RNP) iara@rnp.br * Jos=E9 N. de Souza (UFC) neuman@ufc.br * Jos=E9 Marcos Silva Nogueira jmarcos@dcc.ufmg.br * Keiko V. O. Fonseca (CEFET/PR) keiko@cpgei.cefetpr.br * Liane M. R. Tarouco (UFRGS) liane.tarouco@ufrgs.br * Lisandro Z. Granville (UFRGS) granville@inf.ufrgs.br * Luciano P. Gaspary (UNISINOS) paschoal@exatas.unisinos.br * Luiz Nacamura Jr. (CEFET/PR) nacamura@cpgei.cefetpr.br Important Dates=20 * Paper Submission March 11 2004 * Notification April 8 2004 * Camera-Ready due April 15 2004 Workshop Chair * Elias P. Duarte Jr. (UFPR) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Wed Dec 10 07:03:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08791 for ; Wed, 10 Dec 2003 07:03: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 1AU33Y-0007W6-KO for mmusic-archive@odin.ietf.org; Wed, 10 Dec 2003 07:03:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBAC34sq028888 for mmusic-archive@odin.ietf.org; Wed, 10 Dec 2003 07:03:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU33Y-0007Vr-Fu for mmusic-web-archive@optimus.ietf.org; Wed, 10 Dec 2003 07:03: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 HAA08777 for ; Wed, 10 Dec 2003 07:02:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU33T-0000Jq-00 for mmusic-web-archive@ietf.org; Wed, 10 Dec 2003 07:03:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AU33T-0000Jn-00 for mmusic-web-archive@ietf.org; Wed, 10 Dec 2003 07:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU33V-0007VJ-B7; Wed, 10 Dec 2003 07:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AU33R-0007V7-N6 for mmusic@optimus.ietf.org; Wed, 10 Dec 2003 07:02:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08774 for ; Wed, 10 Dec 2003 07:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AU33N-0000Jj-00 for mmusic@ietf.org; Wed, 10 Dec 2003 07:02:53 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AU33M-0000Jg-00 for mmusic@ietf.org; Wed, 10 Dec 2003 07:02:52 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBAC2rQ24876 for ; Wed, 10 Dec 2003 14:02:53 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 10 Dec 2003 14:02:51 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 10 Dec 2003 14:02:50 +0200 Received: from localhost.localdomain (hed043-205.research.nokia.com [172.21.43.205]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id OAA16739; Wed, 10 Dec 2003 14:02:55 +0200 (EET) Received: from localhost.localdomain (localhost [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id hBAC2Q9j018149; Wed, 10 Dec 2003 14:02:26 +0200 Received: (from ppessi@localhost) by localhost.localdomain (8.12.8/8.12.5/Submit) id hBAC2QGf018148; Wed, 10 Dec 2003 14:02:26 +0200 X-Authentication-Warning: localhost.localdomain: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Colin Perkins Cc: Subject: Re: [mmusic] Inclusion of media type = "text" in SDP 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: (Colin Perkins's message of "Sun, 16 Nov 2003 23:43:39 +0000") References: Date: Wed, 10 Dec 2003 14:02:26 +0200 Message-ID: User-Agent: Gnus/5.09001 (Oort Gnus v0.10) XEmacs/21.4 (Honest Recruiter, i386-redhat-linux) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 10 Dec 2003 12:02:50.0388 (UTC) FILETIME=[889F8540:01C3BF15] 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: , Colin Perkins writes: >> ; sub-rules of 'm=' >> media = token >> ;typically "audio", "video", "text", >> "application" >> ;or "data" >These will be in draft-ietf-mmusic-sdp-new-16. At the same time, it could be a god idea to add also the "message" media. --Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 11 09:07:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01208 for ; Thu, 11 Dec 2003 09:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURT9-0005Pv-1S for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 09:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBE769w020817 for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 09:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURT8-0005Pg-M3 for mmusic-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 09:07: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 JAA01199 for ; Thu, 11 Dec 2003 09:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURT7-0004TC-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 09:07:05 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AURT6-0004T8-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 09:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURT3-0005NG-6G; Thu, 11 Dec 2003 09:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AURSD-0005MI-GO for mmusic@optimus.ietf.org; Thu, 11 Dec 2003 09:06:09 -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 JAA01176 for ; Thu, 11 Dec 2003 09:06:06 -0500 (EST) From: Viktor.Bekesi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AURSB-0004NF-00 for mmusic@ietf.org; Thu, 11 Dec 2003 09:06:07 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AURSB-0004NC-00 for mmusic@ietf.org; Thu, 11 Dec 2003 09:06:07 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBBE65813621 for ; Thu, 11 Dec 2003 16:06:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 11 Dec 2003 15:59:47 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 15:59:44 +0200 Received: from buebe002.NOE.Nokia.com ([10.211.0.51]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 11 Dec 2003 15:59:44 +0200 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: [MMUSIC] rtpmap is legal in session description level Date: Thu, 11 Dec 2003 14:59:43 +0100 Message-ID: Thread-Topic: [MMUSIC] rtpmap is legal in session description level Thread-Index: AcO/7wbwrEB3fU7sTKKSi8osV4crWQ== To: X-OriginalArrivalTime: 11 Dec 2003 13:59:44.0227 (UTC) FILETIME=[079C2B30:01C3BFEF] Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hello, Does the mechanism "if something is not in media description, it is = looked up in the session description" works for attribute fields with = rtpmap attributes? In other words, is it a valid SDP?: v=3D0 o=3Dalice 2890844526 2890844526 IN IP4 10.2.3.4 s=3D c=3DIN IP4 10.2.3.4 t=3D0 0 a=3Drtpmap:97 L16/8000 a=3Drtpmap:98 L16/11025/2 m=3Daudio 49170 RTP/AVP 96 97 98 a=3Drtpmap:96 L8/8000 does the order of the 'a' fields matter? Thanks, best regards: Viktor Bekesi =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 11 10:19:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05695 for ; Thu, 11 Dec 2003 10:19: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 1AUSak-0000Ly-Dl for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 10:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBFJ2Y1001352 for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 10:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSak-0000Lj-99 for mmusic-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 10:19: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 KAA05669 for ; Thu, 11 Dec 2003 10:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSai-0006F3-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 10:19:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUSah-0006F0-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 10: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 1AUSai-0000LD-JG; Thu, 11 Dec 2003 10:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUSaF-0000Kd-KC for mmusic@optimus.ietf.org; Thu, 11 Dec 2003 10:18:31 -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 KAA05611 for ; Thu, 11 Dec 2003 10:18:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUSaD-0006Eg-00 for mmusic@ietf.org; Thu, 11 Dec 2003 10:18:29 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AUSaC-0006Dx-00 for mmusic@ietf.org; Thu, 11 Dec 2003 10:18:29 -0500 Received: from mangole ([130.209.247.112]:1086 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AUSZh-0008FP-00; Thu, 11 Dec 2003 15:17:57 +0000 Date: Thu, 11 Dec 2003 15:18:00 +0000 From: Colin Perkins To: Viktor.Bekesi@nokia.com Cc: mmusic@ietf.org Subject: Re: [MMUSIC] rtpmap is legal in session description level Message-Id: <20031211151800.6191bfd5.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Viktor.Bekesi@nokia.com writes: > Does the mechanism "if something is not in media description, it is > looked up in the session description" works for attribute fields with > rtpmap attributes? According to draft-ietf-mmusic-sdp-new-15, yes. I suspect this is a bug that needs to be fixed, though... Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 11 17:52:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00233 for ; Thu, 11 Dec 2003 17:52: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 1AUZf9-0005qE-WC for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 17:52:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBMq3Iw022448 for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 17:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZf9-0005pz-Qo for mmusic-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 17:52: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 RAA00208 for ; Thu, 11 Dec 2003 17:51:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZf7-0004UD-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 17:52:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUZf6-0004U9-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 17:52:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZf7-0005oa-Gv; Thu, 11 Dec 2003 17:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUZeM-0005ne-G8 for mmusic@optimus.ietf.org; Thu, 11 Dec 2003 17:51:14 -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 RAA00173 for ; Thu, 11 Dec 2003 17:51:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUZeJ-0004SW-00 for mmusic@ietf.org; Thu, 11 Dec 2003 17:51:11 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AUZeI-0004RL-00 for mmusic@ietf.org; Thu, 11 Dec 2003 17:51:11 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:63967 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AUZdo-0000yr-00; Thu, 11 Dec 2003 22:50:40 +0000 Date: Thu, 11 Dec 2003 22:50:42 +0000 From: Colin Perkins To: mmusic@ietf.org Cc: Geetha Srikantan Subject: Re: [MMUSIC] I-D ACTION:draft-srikantan-mmusic-rtsp-streaming-relay-00.txt Message-Id: <20031211225042.3d3309b8.csp@csperkins.org> In-Reply-To: <200312042037.PAA13294@ietf.org> References: <200312042037.PAA13294@ietf.org> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Geetha, all, --> Internet-Drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Streaming Relays > Author(s) : G. Srikantan > Filename : draft-srikantan-mmusic-rtsp-streaming-relay-00.txt > Pages : 0 > Date : 2003-12-4 > > Delivery of streaming media to a large number of clients distributed > across several geographic and network boundaries presents several > challenges in terms of scalability and stream quality. This document > describes N-tier relays to address scalability and quality issues in > the delivery of stored and live content. This document addresses > issues in stream synchronization, content announcement/expiry, > reliability of transport, failover/recovery, administration, and > security issues. This document propose a set of primitives to enable > implementation of Push and Pull mechanisms for N-tier relays. We also > provide usage scenarios where each approach is most useful. The Pull > and Push mechanisms are complementary and provide valuable building > blocks in N-tier relays. This document introduces a few new RTSP > methods and headers. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt Nice survey of the mechanisms and possible solutions. Would you envisage all these approaches being useful for different scenarios, or would it be appropriate to choose a subset which could be written up as a BCP - perhaps along with some standard RTSP extensions? -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 11 18:34:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03058 for ; Thu, 11 Dec 2003 18:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaJn-0007RC-2a for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 18:34:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBBNY3tZ028589 for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 18:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaJm-0007R2-Sf for mmusic-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 18:34: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 SAA03054 for ; Thu, 11 Dec 2003 18:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaJj-0005Yj-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 18:33:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUaJj-0005Yg-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 18:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaJl-0007QV-Bm; Thu, 11 Dec 2003 18:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUaJP-0007QE-Vl for mmusic@optimus.ietf.org; Thu, 11 Dec 2003 18:33:39 -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 SAA03051 for ; Thu, 11 Dec 2003 18:33:35 -0500 (EST) From: juha-pekka.luoma@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUaJM-0005YZ-00 for mmusic@ietf.org; Thu, 11 Dec 2003 18:33:36 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AUaJM-0005YW-00 for mmusic@ietf.org; Thu, 11 Dec 2003 18:33:36 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBBNXZ821154 for ; Fri, 12 Dec 2003 01:33:35 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 12 Dec 2003 01:33:36 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 01:33:34 +0200 Received: from trebe004.NOE.Nokia.com ([172.22.232.177]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 12 Dec 2003 01:33:34 +0200 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: Fri, 12 Dec 2003 01:33:34 +0200 Message-ID: <481D6FFB3BD60E4CB590F39C59098400024F7B86@trebe004.europe.nokia.com> Thread-Topic: IMG Reqs & FW IDs: next steps / actions Thread-Index: AcO87No5zJeJq6juSJGUJhANV53crQAg8xfwAJit8XA= To: X-OriginalArrivalTime: 11 Dec 2003 23:33:34.0705 (UTC) FILETIME=[31C62E10:01C3C03F] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Plans for WGLC - IMG Requirements and Framework Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi all, In the MMUSIC session of IETF-58, we presented the status of our work on = the Internet Media Guide (IMG) Requirements and Framework. A number of = open issues in the two drafts were identified both in the MMUSIC session = and in offline discussions. To address these, we have updated these = drafts already once after IETF-58 and will shortly publish version 02 of = the drafts. As mentioned in our MMUSIC presentation, we would like to = have a Working Group Last Call for the drafts this month after resolving = the remaining issues. (1) Use Cases: Framework -> Requirements (2) Consider an alternative to the term "IMG Metadata" (3) Consider the text on baseline data model (4) Decide on the published status of these after freeze Our group of IMG draft authors had the following notes on the list = items. (1): Easy to do, will do for 02. (2): There is a risk of indefinite delay here to people who did not find = a better term in 12 months. The risk in our opinion outweighs the = benefits of getting the term just right. We've done terminology = clean-ups and reviews, and provided an accurate definition to the term = "IMG metadata" that is used consistently. Our only good alternative "IMG = information" is no less ambiguous than the existing term, so we would = prefer the term as is. However, if there are some exact wording = proposals this would be very helpful. =20 (3): We thought it would be useful to very briefly introduce this topic, = even if outside MMUSIC scope, as it is impossible to have a metadata = format independent application without some kind of baseline data model = to plug the app-specific metadata into. (4): Informational RFC is a good target for the two drafts.=20 We are very interested in getting your review and input on the drafts, = either this version (links below) or the next. Please, share your = comments!=20 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-01.tx= t Comments are also welcome to the following individual draft defining the = IMG transfer envelope format. http://www.ietf.org/internet-drafts/draft-luoma-mmusic-img-metadata-envel= ope-00 -Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 11 19:10:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04118 for ; Thu, 11 Dec 2003 19:10:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUasn-00016Y-7B for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBC0AD7G004240 for mmusic-archive@odin.ietf.org; Thu, 11 Dec 2003 19:10:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUasn-00016J-1Y for mmusic-web-archive@optimus.ietf.org; Thu, 11 Dec 2003 19:10:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04005 for ; Thu, 11 Dec 2003 19:10:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUasj-00068C-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:09 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUasj-000689-00 for mmusic-web-archive@ietf.org; Thu, 11 Dec 2003 19:10:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUasi-00010u-5w; Thu, 11 Dec 2003 19:10:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUas3-0000o2-BR for mmusic@optimus.ietf.org; Thu, 11 Dec 2003 19:09:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03945 for ; Thu, 11 Dec 2003 19:09:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUarz-00066W-00 for mmusic@ietf.org; Thu, 11 Dec 2003 19:09:23 -0500 Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx with esmtp (Exim 4.12) id 1AUarz-00065P-00 for mmusic@ietf.org; Thu, 11 Dec 2003 19:09:23 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hBC08qw05980 for ; Thu, 11 Dec 2003 19:08:52 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Dec 2003 19:08:53 -0500 Message-ID: From: "Kevin Boyle" To: Stephen Casner , Rajesh Kumar Cc: Colin Perkins , mmusic@ietf.org, flemming Andreasen , mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: RE: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Thu, 11 Dec 2003 19:08:51 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , All, Looking back at this email stream, one question remains outstanding in my mind: What if the two m= lines have the SAME media type? For instance: m=audio 49232 RTP/AVP 18 m=image 49233 UDPTL t38 m=audio 49232 RTP/AVP 100 a=rtpmap:100 PCMU/8000 a=gpmd:100 vbd=yes For some of the SDP-based protocols, the order of appearance is vital because it announces preference. So, this shows preference for T.38 fax relay over PCMU VBD for fax, while utilizing G.729 for voice. As far as I can tell, this construct is allowed, since both m lines using the same port number use a media type of audio. Is my understanding correct? Thanks, Kevin -----Original Message----- From: Stephen Casner [mailto:casner@acm.org] Sent: Friday, April 25, 2003 2:57 PM To: Rajesh Kumar Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; paulej@cisco.com Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number Rajesh, > Is the use of multiple 'm=' lines with the same port number within an > SDP descriptor permitted? Presuming that the multiple m= lines are all RTP/AVP, then doing so causes all of the payload formats listed on the m= lines to become part of a single RTP session (unless they are distinguished by some other aspect of addressing). Section 5.2 of the RTP spec addresses NOT multiplexing different media in the same RTP session. > In SDP, as it is defined, all the media formats on an 'm=' line are of > the same media type (e.g. audio, image, text etc.). > > Now consider the case in which two RTP media formats can use a > destination port but are registered under different MIME types. For > example, text/t140 and audio/PCMU. In this case, there is no recourse > except to use multiple media lines with the same port number. For example: The "can use a destination port" is the tricky part. We may not agree. > m=audio 49232 RTP/AVP 0 > m=text 49232 RTP/AVP 100 > a=rtpmap:100 t140 > > My thought is that although this is unsual, it is not proscribed by > SDP syntax in RFC 2327 or in its latest internet draft. I believe this is proscribed by section 5.2 of the RTP spec because these two media should not be multiplexed in one RTP session. My bet is that the real example you are thinking about is fax or modem over IP. We've been there before. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 05:21:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03551 for ; Fri, 12 Dec 2003 05:21:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkQ0-0003j8-I5 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 05:21:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCAL8oE014320 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 05:21:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkQ0-0003it-3J for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 05:21:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03538 for ; Fri, 12 Dec 2003 05:21:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUkPw-0001be-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 05:21:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUkPw-0001bb-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 05:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkPu-0003i1-DM; Fri, 12 Dec 2003 05:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUkPC-0003fz-NY for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 05:20:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03532 for ; Fri, 12 Dec 2003 05:20:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUkP9-0001bP-00 for mmusic@ietf.org; Fri, 12 Dec 2003 05:20:15 -0500 Received: from mail.com.dtu.dk ([192.38.68.3] helo=com.dtu.dk) by ietf-mx with esmtp (Exim 4.12) id 1AUkP8-0001bA-00 for mmusic@ietf.org; Fri, 12 Dec 2003 05:20:15 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Fri, 12 Dec 2003 11:19:45 +0100 Message-ID: Thread-Topic: Recursive definition in "Absolute Time" in RTSP thread-index: AcPAmXbdJrwHr0boQXueKYK4gZU4Jg== From: "Philip Grove" To: Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] Recursive definition in "Absolute Time" in RTSP Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable When I read the grammar for the absolute time format in RTSP both in RFC 2326 and in draft-ietf-mmusic-rfc2326bis-05.txt I stumbled across a recursive definition. In both documents you can find this text: utc-time =3D utc-date "T" utc-time "Z" utc-date =3D 8DIGIT ; < YYYYMMDD > utc-time =3D 6DIGIT [ "." fraction ] ; < HHMMSS.fraction > Which gives two definitions for utc-time of which the first happens to be recursive. Fixing this only involves changing the name of one of the definitions, but have two definitions for utc-time can lead to some confusion. Philip Grove _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 07:22:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05658 for ; Fri, 12 Dec 2003 07:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmJ4-0007gm-Ti for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 07:22:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCCM6A5029550 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 07:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmJ4-0007gX-ON for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 07:22: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 HAA05630 for ; Fri, 12 Dec 2003 07:22:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUmJ4-00036d-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 07:22:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUmJ3-00036a-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 07:22:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmIz-0007g1-CB; Fri, 12 Dec 2003 07:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmIt-0007fJ-GF for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 07:21:55 -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 HAA05623 for ; Fri, 12 Dec 2003 07:21:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUmIs-00036K-00 for mmusic@ietf.org; Fri, 12 Dec 2003 07:21:55 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AUmIs-000363-00 for mmusic@ietf.org; Fri, 12 Dec 2003 07:21:54 -0500 Received: from cisco.com (sjc-vpn2-412.cisco.com [10.21.113.156]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBCCLJrX029097; Fri, 12 Dec 2003 04:21:19 -0800 (PST) Message-ID: <3FD9B2BE.1BFCE081@cisco.com> Date: Fri, 12 Dec 2003 07:21:18 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kevin Boyle CC: Stephen Casner , Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kevin Boyle wrote: > > > All, > > Looking back at this email stream, one question remains outstanding in > my mind: > > What if the two m= lines have the SAME media type? For instance: > > m=audio 49232 RTP/AVP 18 > m=image 49233 UDPTL t38 > m=audio 49232 RTP/AVP 100 > a=rtpmap:100 PCMU/8000 > a=gpmd:100 vbd=yes > > For some of the SDP-based protocols, the order of appearance is vital > because it announces preference. Only for the media formats within a given "m=" line. Multiple "m=" lines indicates a set of simultaneous media streams; not alternatives. > So, this shows preference for T.38 fax relay over PCMU VBD for fax, > while utilizing G.729 for voice. As far as I can tell, this construct > is allowed, since both m lines using the same port number use a media > type of audio. > > Is my understanding correct? > Not quite. Each "m=" line corresponds to a separate media stream. Also, the consensus of this discussion has been that you are *not* allowed to use the same port for different media lines, regardless of whether they share the same top-level MIME type or not. -- Flemming > > Thanks, > > Kevin > > -----Original Message----- > From: Stephen Casner [mailto:casner@acm.org] > Sent: Friday, April 25, 2003 2:57 PM > To: Rajesh Kumar > Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > paulej@cisco.com > > Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > > Rajesh, > > > Is the use of multiple 'm=' lines with the same port number within > an > > SDP descriptor permitted? > > Presuming that the multiple m= lines are all RTP/AVP, then doing so > causes all of the payload formats listed on the m= lines to become > part of a single RTP session (unless they are distinguished by some > other aspect of addressing). Section 5.2 of the RTP spec addresses > NOT multiplexing different media in the same RTP session. > > > In SDP, as it is defined, all the media formats on an 'm=' line are > of > > the same media type (e.g. audio, image, text etc.). > > > > Now consider the case in which two RTP media formats can use a > > destination port but are registered under different MIME types. For > > example, text/t140 and audio/PCMU. In this case, there is no > recourse > > except to use multiple media lines with the same port number. For > example: > > The "can use a destination port" is the tricky part. We may not > agree. > > > m=audio 49232 RTP/AVP 0 > > m=text 49232 RTP/AVP 100 > > a=rtpmap:100 t140 > > > > My thought is that although this is unsual, it is not proscribed by > > SDP syntax in RFC 2327 or in its latest internet draft. > > I believe this is proscribed by section 5.2 of the RTP spec because > these two media should not be multiplexed in one RTP session. > > My bet is that the real example you are thinking about is fax or modem > over IP. We've been there before. > > -- Steve > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 07:44:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06088 for ; Fri, 12 Dec 2003 07:44: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 1AUmeI-0008SO-FC for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 07:44:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCCi2fC032502 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 07:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmeI-0008S9-9N for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 07:44: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 HAA06062 for ; Fri, 12 Dec 2003 07:44:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUmeH-0003Ov-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 07:44:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUmeH-0003Os-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 07:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmeG-0008RX-EC; Fri, 12 Dec 2003 07:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUmdv-0008Qg-ML for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 07:43:39 -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 HAA06045 for ; Fri, 12 Dec 2003 07:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUmdu-0003ON-00 for mmusic@ietf.org; Fri, 12 Dec 2003 07:43:38 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AUmdu-0003OD-00 for mmusic@ietf.org; Fri, 12 Dec 2003 07:43:38 -0500 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hBCChWSs027120; Fri, 12 Dec 2003 13:43:32 +0100 (MET) Received: from ericsson.com (research-nnng7k.ki.sw.ericsson.se [147.214.34.132]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XW7WBHWL; Fri, 12 Dec 2003 13:43:30 +0100 Message-ID: <3FD9B7EB.6000500@ericsson.com> Date: Fri, 12 Dec 2003 13:43:23 +0100 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Flemming Andreasen , Mark Baugher , Dan Wing CC: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Commetns on draft-ietf-mmusic-sdescriptions-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I have know read the draft and has thought about most of the open issues that the draft presents and the discussion during the IETF meeting. There are a couple of points below that, especially 5, that I believe requires further discussion and study. 1. As a general thing I think authors should think about how the pages get clipped by the pages. For improved readability one should move any new sections, etc. that only gets a few line to the next page. One such example is to start the table of contents on the first page, instead of on the second. Another if the section 4 heading that are sole on the last line of a page. 2. The table contents may be a bit to detailed, I would think that it would be acceptable to remove all third level items. 3. The introduction contains a normative MUST. I don't think this is really appropriate. Please find another place to locate this normative text after the introduction. 4. In the last paragraph of section 2, I think this section would benefit of being split into two paragraphs. 5. I think that one must look over the multicast cases and divide them into different use cases. I think that removing all the multicast is a bad choice as there are situation where it seems to work. I would start by dividing the usage into scenarios where one can use the a=crypto successfully. - The one to many, using ASM case. This is a advertisement case. Only the intended sender declares his SSRC/ROC/SEQ to ensure that all receivers does not use the senders SSRC and causes a two time pad with it. As all receivers are unsynchronized unless other mechanism is used, there might happen SSRC collisions. However if you either don't encrypt the RTCP, which is the only thing they will send, it is not a problem. Also if RTCP encryption is used, it might be deemed acceptable with the low risk of two time pads that exist. However this is clearly a security trade off. - The one to many, using SSM, as the receivers can't send to anybody else there is no problem. If one uses unicast RTCP feedback, the same security consideration regarding RTCP two time pads apply, however the distribution of the offending packets will not be the same as for ASM use cases. - The multicast conference case, with a central session control instance. As all participants speak only with the central control entity it can ensure that SSRC, collision is avoided if the same key are used. However in this case it is probably better to use individual master keys for each sender. However there seems to be some need to fix the a=crypto syntax to support this case. - The multicast conference, each sender announces there attributes individually to each participant. In this case all should be required to use individual master keys. Thus there is no risk for two time pads. As I see it with a few changes to the a=crypto attribute multicast can be fixed. However there is need to flesh out the scenarios and ensure that the signalling works for these. So as a conclusion there is need for more work in the multicast environment. Also statement as the second bullet in 4.1.1.2 is not correct. 6. void 7. Section 5.1.1.1 the example line includes a extra "<" at the "lifetime" parameter. 8. Section 5.1.1.1: How does one know what type of key that is specified in the key field. To my understanding there are a possibility for at least three different levels of keys in SRTP. A top level master key, a master key for a single SSRC, individual keys for streams. There is currently no way of differentiating or requiring a key to be of a certain type. 9. In section 5.1.1.1 there is a rule that the key length must be correct for the signalled length. However a BASE64 encoded key|salt combination may need some padding. So I assume that key lengths changing it to up to the next base64 boundary is okay. 10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about how the number of packets are calculated and applies to. Is this the total number of packets a master key can be used for, or does it applies to any derived key, and when one of the derived keys reach this number it needs to rekey? I don't think the text in section 5.3.1 really helps either, as it makes it impossible for individual participants to actually calculate how many packets that has been used by the master key. 11. Section 5.2, I think this section could gain by an table that tabulates the crypto suits and its major parameters for easy access instead of the description. 12. Section 5.3.1: The SRC parameter I think need to be better clarified. If one gives a ROC/SEQ is given, it MUST be given in relation to the SSRC for which it is valid. 13. When it comes to offer answer for multicast, it must be made clear how one uses SRC to ensure that a joining participant selects a SSRC that will not collide. 14. Section 5.3.1, what is an invalid SSRC? How do you know. 15. How is the the usage of late binding and shared master key indicated, to allow a receiver to determine what is used. 16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key derivation should be performed every packet. I would recommend to remove this wrong motivation, and simply state it as being an exception. 17. In 6.1.1.2 you have a restriction that from-to must only be used in "recvonly", doesn't this depend on the scoping of these attributes. As pointed out in point 10, the from to context is not clear. 18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one? 19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with SSRC when common master key is used. 20. In 6.1.2.1, Before the open issue, there is a statement that the is no need for optional parameters. I think this is not, true or what is meant with optional parameters must be clarified, there are certain use case that definitely will require use of certain parameters. 21. In 6.1.3.2 , there is text saying that session parameters shall be ignored, I don't agree with that. 22. In 6.1.3, In the paragraph after the bullets, one may get the impression that multiple sources only are needed in multicast. That is not true. Also in unicast a single end-point may need to use multiple SSRCs, for example for retransmission. 23. In 7.3, I think the RECOMMEND to use a key management protocol if not carried in authenticated and encrypted transport format, should be a SHOULD. 24, Section 7.3, Question, How does one know that the signalling over network (b) even is encrypted. 25. Section 8: "key-params" does not need to be recursively defined, the second "key-params", needs only to be a "key-param" 26. Section 8.1: key-method-ext, isn't this a "token"? I think restricting the usage of other special characters then "_" is possibly to restricted. 27. Section 8.2, is really decimal form for SSRC the best form. I would recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 bit binary identifier, not a number in its normal sense. 28. Section 10.2.1, I think that you should review the standard IANA registration levels in RFC 2434, I think that for the key method, it is probably, "standards action" that is the right one. 29. Section 10.2.2: I don't think that SRTP crypto suit registrations needs only to take "inline" into consideration. I think it should say that it should be defined in relation to applicable key-methods. I also think that the IANA section should be a bit more explicit what really is required. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 11:16:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14578 for ; Fri, 12 Dec 2003 11:16: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 1AUpxD-0001Kv-PU for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 11:15:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCGFlmn005133 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 11:15:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpxC-0001Ki-7n for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 11:15:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14558 for ; Fri, 12 Dec 2003 11:15:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpxB-0000J4-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 11:15:45 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUpws-0000Il-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 11:15:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpwU-0001Hl-B4; Fri, 12 Dec 2003 11:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUpwI-0001HI-3s for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 11:14:51 -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 LAA14529 for ; Fri, 12 Dec 2003 11:14:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUpwH-0000IQ-00 for mmusic@ietf.org; Fri, 12 Dec 2003 11:14:49 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AUpwG-0000Hg-00 for mmusic@ietf.org; Fri, 12 Dec 2003 11:14:48 -0500 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id hBCGEHr7003201 for ; Fri, 12 Dec 2003 08:14:17 -0800 (PST) Received: from jamba (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 <0HPS00I73IFTWK@mpk-mail1.sfbay.sun.com> for mmusic@ietf.org; Fri, 12 Dec 2003 08:14:17 -0800 (PST) Date: Fri, 12 Dec 2003 08:14:56 -0800 From: Geetha Srikantan Subject: Re: [MMUSIC] I-D ACTION:draft-srikantan-mmusic-rtsp-streaming-relay-00.txt In-reply-to: <20031211225042.3d3309b8.csp@csperkins.org> To: Colin Perkins Cc: mmusic@ietf.org Message-id: <1071245696.2505.27.camel@jamba> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.2.4.99 Content-type: text/plain Content-transfer-encoding: 7bit References: <200312042037.PAA13294@ietf.org> <20031211225042.3d3309b8.csp@csperkins.org> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Colin, Thanks for reviewing the document. More inline.. On Thu, 2003-12-11 at 14:50, Colin Perkins wrote: > Geetha, all, > > --> Internet-Drafts@ietf.org writes: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > Title : Streaming Relays > > Author(s) : G. Srikantan > > Filename : draft-srikantan-mmusic-rtsp-streaming-relay-00.txt > > Pages : 0 > > Date : 2003-12-4 > > > > Delivery of streaming media to a large number of clients distributed > > across several geographic and network boundaries presents several > > challenges in terms of scalability and stream quality. This document > > describes N-tier relays to address scalability and quality issues in > > the delivery of stored and live content. This document addresses > > issues in stream synchronization, content announcement/expiry, > > reliability of transport, failover/recovery, administration, and > > security issues. This document propose a set of primitives to enable > > implementation of Push and Pull mechanisms for N-tier relays. We also > > provide usage scenarios where each approach is most useful. The Pull > > and Push mechanisms are complementary and provide valuable building > > blocks in N-tier relays. This document introduces a few new RTSP > > methods and headers. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt > > Nice survey of the mechanisms and possible solutions. Would you envisage > all these approaches being useful for different scenarios, or would it be > appropriate to choose a subset which could be written up as a BCP - perhaps > along with some standard RTSP extensions? We see these approaches as being useful individually and in combination, depending on the scenario. The RTSP methods and headers needed are as summarized below. It would be great to get these into the core RTSP spec, if not, then as an RTSP extension. Methods for content availability notification and server capability detection in both Push and Pull mechanisms: ANNOUNCE for multicast Push ANNOUNCE_RELAY for unicast Pull ANNOUNCE_RECEIVE for unicast Push Methods for Push mechanism: SETUP with mode=receive RECEIVE Headers to be used with ANNOUNCE* methods for both Push and Pull mechanisms: Content-Lifetime: - Content-Revoke: Alternate-Source: Recovery: ; ; I'm not sure what BCP is..would you elaborate? thanks geetha -- Geetha Srikantan _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 13:13:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18635 for ; Fri, 12 Dec 2003 13:13:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrmg-0007u3-19 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 13:13:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBCID1AS030373 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 13:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrmf-0007to-Qi for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 13:13:01 -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 NAA18610 for ; Fri, 12 Dec 2003 13:12:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrmd-0003FG-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 13:12:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AUrmd-0003FD-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 13:12:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrme-0007tH-Dt; Fri, 12 Dec 2003 13:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AUrlg-0007ls-NG for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 13:12: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 NAA18583 for ; Fri, 12 Dec 2003 13:11:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AUrle-0003E9-00 for mmusic@ietf.org; Fri, 12 Dec 2003 13:11:58 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AUrld-0003DX-00 for mmusic@ietf.org; Fri, 12 Dec 2003 13:11:57 -0500 Received: from mangole ([130.209.247.112]:1116 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AUrl5-00032C-00; Fri, 12 Dec 2003 18:11:23 +0000 Date: Fri, 12 Dec 2003 18:11:26 +0000 From: Colin Perkins To: Geetha Srikantan Cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-srikantan-mmusic-rtsp-streaming-relay-00.txt Message-Id: <20031212181126.6536fce9.csp@csperkins.org> In-Reply-To: <1071245696.2505.27.camel@jamba> References: <200312042037.PAA13294@ietf.org> <20031211225042.3d3309b8.csp@csperkins.org> <1071245696.2505.27.camel@jamba> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.7 (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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, --> Geetha Srikantan writes: > On Thu, 2003-12-11 at 14:50, Colin Perkins wrote: ... > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-srikantan-mmusic-rtsp-streaming-relay-00.txt > > > > Nice survey of the mechanisms and possible solutions. Would you > > envisage all these approaches being useful for different scenarios, or > > would it be appropriate to choose a subset which could be written up as > > a BCP - perhaps along with some standard RTSP extensions? > > We see these approaches as being useful individually and in combination, > depending on the scenario. The RTSP methods and headers needed are > as summarized below. It would be great to get these into the core RTSP > spec, if not, then as an RTSP extension. > > Methods for content availability notification and server capability > detection in both Push and Pull mechanisms: > > ANNOUNCE for multicast Push > ANNOUNCE_RELAY for unicast Pull > ANNOUNCE_RECEIVE for unicast Push > > Methods for Push mechanism: > SETUP with mode=receive > RECEIVE > > Headers to be used with ANNOUNCE* methods for both Push and Pull > mechanisms: > Content-Lifetime: - > Content-Revoke: > Alternate-Source: > Recovery: ; ; > Do we need all of these? It would ease interoperability if we could define a single approach that worked for all scenarios, and this may even be worth doing if the result is a little less optimal. > I'm not sure what BCP is..would you elaborate? A "Best Current Practice" RFC, as a way of describing how other existing components can be combined to solve a particular class of problem. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 12 23:15:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11975 for ; Fri, 12 Dec 2003 23:15:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV1BB-0001LT-Is for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 23:14:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBD4EvBo005168 for mmusic-archive@odin.ietf.org; Fri, 12 Dec 2003 23:14:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV1B9-0001LG-6W for mmusic-web-archive@optimus.ietf.org; Fri, 12 Dec 2003 23:14:55 -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 XAA11965 for ; Fri, 12 Dec 2003 23:14:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV1B6-0002LW-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 23:14:52 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AV1Al-0002LD-00 for mmusic-web-archive@ietf.org; Fri, 12 Dec 2003 23:14:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV1AG-0001GI-Tz; Fri, 12 Dec 2003 23:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AV19p-0001Fn-FP for mmusic@optimus.ietf.org; Fri, 12 Dec 2003 23:13: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 XAA11939 for ; Fri, 12 Dec 2003 23:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AV19m-0002Ki-00 for mmusic@ietf.org; Fri, 12 Dec 2003 23:13:30 -0500 Received: from tog-wakko4.prognet.com ([207.188.29.244] helo=goobox) by ietf-mx with esmtp (Exim 4.12) id 1AV19k-0002Kd-00 for mmusic@ietf.org; Fri, 12 Dec 2003 23:13:28 -0500 Date: Fri, 12 Dec 2003 20:08:37 -0800 From: rtspspec-bugs-request@lists.sourceforge.net Message-Id: To: mmusic@ietf.org Reply-to: mmusic@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_goobox-17433-1071288772-0001-2" Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #111 - 1 msg Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_goobox-17433-1071288772-0001-2 Content-Type: text/plain; format=flowed; charset=iso-8859-1 Comment: The following content can be customized provided that: Comment: 1) These MIME headers are preserved (you may change the charset Comment: or drop format=flowed). Comment: 2) This content is manually quoted-printable encoded, it MUST NOT Comment: contain 8-bit text. Comment: 'goobox' below is replaced by server name. Content-Transfer-Encoding: quoted-printable CORRUPTED MESSAGE This is the Courier Mail Server 0.36.1 on goobox. I received the following message for delivery to your address. Unfortunately, this message apparently fails to comply with Internet mail formatting protocols, and I can only deliver mail which has been properly formatted in accordance with Internet standards. Instead of rejecting that message as undeliverable, I saved it as the following attachment, which you can open with any editor or word processor. Please notify the original sender that their message was not properly formatted by their mail software. The specific mail protocol error is as follows: ----------------------------------------------------------------------------- The following message contains 8-bit content, but does not have the required MIME headers for 8-bit data transport. See for more information. ----------------------------------------------------------------------------- --=_goobox-17433-1071288772-0001-2 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: attachment; filename="message.txt" X-Mime-Autoconverted: from 8bit to quoted-printable by courier 0.36.1 Content-Transfer-Encoding: quoted-printable Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 12 Dec 2003 20:12:51 -0800 Delivered-To: robla@real.com >Return-Path: Received: from mailone.real.com [207.188.7.222] by localhost with POP3 (= fetchmail-6.2.0) for robla@localhost (single-drop); Fri, 12 Dec 2003 20:= 12:50 -0800 (PST) Received: from sc8-sf-mx1.sourceforge.net ([::ffff:66.35.250.206]) (TLS:= TLSv1/SSLv3,168bits,DES-CBC3-SHA) by goodfellas.real.com with esmtp; Fr= i, 12 Dec 2003 20:11:43 -0800 Received: from sc8-sf-list1-b.sourceforge.net ([10.3.1.7] helo=3Dsc8-sf-= list1.sourceforge.net) by sc8-sf-mx1.sourceforge.net with esmtp (TLSv1:A= ES256-SHA:256) (Exim 4.24) id 1AV17Z-00035s-TH for robla@real.com; Fri, = 12 Dec 2003 20:11:14 -0800 Received: from localhost.localdomain ([127.0.0.1] helo=3Dprojects.source= forge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.24) id 1AV= 17Z-0004Wp-OL for robla@real.com; Fri, 12 Dec 2003 20:11:13 -0800 Date: Fri, 12 Dec 2003 20:08:37 -0800 From: rtspspec-bugs-request@lists.sourceforge.net Subject: Rtspspec-bugs digest, Vol 1 #111 - 1 msg X-Mailer: Mailman v2.0.9-sf.net MIME-version: 1.0 Content-type: text/plain Old-To: rtspspec-bugs@lists.sourceforge.net Sender: rtspspec-bugs-admin@lists.sourceforge.net Errors-To: rtspspec-bugs-admin@lists.sourceforge.net X-BeenThere: rtspspec-bugs@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk Message-Id: X-Spam-Score: 0.3 (/) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on goo= dfellas.real.com X-Spam-Status: No, hits=3D-4.7 required=3D5.0 tests=3DAWL,BAYES_00,NO_RE= AL_NAME autolearn=3Dno version=3D2.60 X-Spam-Level: To: mmusic@ietf.org Reply-to: mmusic@ietf.org This is an automatic digest of bugs submitted and changed on the RTSP bu= g tracker. To see a list of bugs, visit: http://sf.net/projects/rtspspec When replying, please make your Subject line more specific than "Re: Rts= pspec-bugs digest" Today's Topics: 1. =3D?GB2312?B?s8/Qxbf+zvGjrMirufrK17zSzcaz9r/J0tTD4rfRz8jX9s341b6jo= Q=3D=3D?=3D (=3D?GB2312?B?uuPL2bTvzfjC5w=3D=3D?=3D) --__--__-- Message: 1 From: =3D?GB2312?B?uuPL2bTvzfjC5w=3D=3D?=3D To: rtspspec-bugs@lists.sourceforge.net Reply-To: xmhsd@tom.com Date: Fri, 12 Dec 2003 15:52:25 +0800 Subject: [rtspspec-bugs] =3D?GB2312?B?s8/Qxbf+zvGjrMirufrK17zSzcaz9r/J0t= TD4rfRz8jX9s341b6joQ=3D=3D?=3D =D7=F0=BE=B4=B5=C4=D0=C2=C0=CF=BF=CD=BB=A7=A3=BA =A1=A1=A1=A1=C4=FA=BA=C3=A3=AC=BA=DC=B8=DF=D0=CB=C4=DC=CE=AA=C4=FA=B7=FE= =CE=F1=A3=A1 =A1=A1=A1=A1=C8=E7=B9=FB=C4=FA=BB=F2=C4=FA=B5=C4=C6=F3=D2=B5=CF=EB=D7=F6= =CD=F8=D5=BE=A3=AC=B8=F8=CE=D2=C3=C7=B8=F6=BB=FA=BB=E1=A3=AC=BE=F8=B6=D4= =C8=C3=C4=FA=C2=FA=D2=E2=A3=A1=A3=A1=A3=A1 =CE=D2=CB=BE=B7=FE=CE=F1=CF=EE=C4=BF=A3=BA=CD=F8=D2=B3=D6=C6=D7=F7=A1=A2= =D3=F2=C3=FB=D7=A2=B2=E1=A1=A2=D0=E9=C4=E2=D6=F7=BB=FA=A1=A2=CD=F8=D5=BE= =CD=C6=B9=E3=A1=A2=CD=A8=D3=C3=CD=F8=D6=B7=B5=C8=A3=BB =B7=FE=CE=F1=D3=C5=CA=C6=A3=BA=D3=F2=C3=FB=D7=A2=B2=E1=D6=BB=CA=D5=C8=A1= =CA=D6=D0=F8=B7=D1=A3=AC=D0=E9=C4=E2=D6=F7=BB=FA=D7=E2=D3=C3=CC=D8=BB=DD= =BC=DB=A3=BB =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=C6=F3=D2=B5=BC=B0=B8=F6=C8=CB=BE=F9=BF=C9= =C9=EA=C7=EB=B3=C9=CE=AA=CE=D2=C3=C7=B5=C4=B4=FA=C0=ED=A3=AC=BB=F1=C8=A1= =B8=FC=B4=F3=D3=C5=BB=DD=A3=BB =D7=A8=D2=B5=CD=F8=D5=BE=D3=C5=BB=DD=BC=DB=D6=C6=D7=F7=A3=AC=BE= =AB=B3=CF=B4=F2=D4=EC=CA=B5=C1=A6=CD=F8=D5=BE=A3=AC=CE=AA=C4=FA=BD=DA=CA= =A1=C3=BF=D2=BB=B7=D6=C7=AE=A3=BB =CC=D8=B1=F0=CB=B5=C3=F7=A3=BA=B6=D4=D3=DA=D0=C5=D3=FE=BA=C3=B5=C4=C6=F3= =D2=B5=D0=E8=D2=AA=D7=F6=CD=F8=D5=BE=B5=C4=CE=D2=CB=BE=BF=C9=D2=D4=B2=BB= =CA=D5=D2=BB=B7=D6=C7=AE=CF=C8=B8=F8=D3=E8=D7=F6=BA=C3=A3=AC =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=C2=FA=D2=E2=BA=F3=D4=D9=CA=D5=B7=D1=A1=A3 "=B8=DF=CB=D9=A1=A2=CE=C8=B6=A8=A1=A2=B0=B2=C8=AB=A1=A224=D0=A1=CA=B1=D7= =A8=D2=B5=B7=FE=CE=F1"=CA=C7=C8=AB=CC=E5=BA=E3=CB=D9=B4=EF=C8=CB=B5=C4=B7= =FE=CE=F1=D7=DA=D6=BC=A3=AC=CE=D2=C3=C7=D6=A3=D6=D8=B3=D0=C5=B5=A3=BA 1=A1=A2=BA=E3=CB=D9=B4=EF=D6=F7=BB=FA=C8=AB=B2=BF=B2=C9=D3=C3=D7=EE= =D0=C2=D4=AD=D7=B0Dell PowerApp=BB=A5=C1=AA=CD=F8=D3=A6=D3=C3=B7=FE=CE=F1= =C6=F7=A3=BB 2=A1=A2=B9=E2=CF=CB=D6=B1=BD=D3=BD=D3=C8=EB=A3=AC=D6=F7=BB=FA=B6=C0= =CF=ED 100M =B4=F8=BF=ED=A3=AC=CD=AC=CA=B1=CD=D0=B9=DC=D3=DA=CD=F8=CD=A8= =D3=EB=B5=E7=D0=C5=A3=BB 3=A1=A2=BA=E3=CB=D9=B4=EF=D6=F7=BB=FA=C8=AB=B2=BF=B0=B2=D7=B0=D5=FD= =B0=E6Turbolinux=BB=F2Microsoft=B2=D9=D7=F7=CF=B5=CD=B3=A3=BB 4=A1=A2=B2=C9=D3=C3=CA=C0=BD=E7=B1=EA=D7=BC=B5=C4SNMP=BD=F8=D0=D024= x7x365 =CF=B5=CD=B3=BC=E0=B2=E2=A3=BB 5=A1=A2=BA=E3=CB=D9=B4=EF=D6=F7=BB=FA=BF=CD=BB=A7=D2=BB=B8=F6=D4=C2= =C4=DA=BF=C9=CE=DE=CC=F5=BC=FE=C8=AB=B6=EE=CD=CB=BF=EE=A3=BB=C6=E4=CB=FC= =B0=B4=CA=B5=BC=CA=D3=E0=B6=EE=CD=CB=BF=EE=A1=A3 =D0=E9=C4=E2=D6=F7=BB=FA=CE=D2=CB=BE=CB=F9=CD=C6=B3=F6=B5=C4=CC=D7=B2=CD= =D7=E9=BA=CF=D3=D0=D2=D4=CF=C2=BC=B8=D6=D6=D3=C5=BB=DD=A3=BA 1=A1=A2100M=A3=A8=B4=BFHTML=BF=D5=BC=E4=A3=A9+ =CB=CD=D2=BB=B9=FA=BC=CA= =D3=F2=C3=FB=A3=AC=BD=F6=CA=DB150=D4=AA/=C4=EA 2=A1=A250M=BF=D5=BC=E4+50M=C6=F3=D2=B5=D3=CA=BE=D6 + =B9=A6=C4=DC=C8=AB= =C3=E6=D6=A7=B3=D6=B2=A2=CB=CD=D2=BB=B9=FA=BC=CA=D3=F2=C3=FB=A3=AC=BD=F6= =CA=DB248=D4=AA/=C4=EA 3=A1=A2100MP=BF=D5=BC=E4+100M=C6=F3=D2=B5=D3=CA=BE=D6 + =B9=A6=C4=DC=C8= =AB=C3=E6=D6=A7=B3=D6=B2=A2=CB=CD=D2=BB=B9=FA=BC=CA=D3=F2=C3=FB=A3=AC=BD= =F6=CA=DB280=D4=AA/=C4=EA 4=A1=A2200MP=BF=D5=BC=E4+200M=C6=F3=D2=B5=D3=CA=BE=D6 + =B9=A6=C4=DC=C8= =AB=C3=E6=D6=A7=B3=D6=B2=A2=CB=CD=D2=BB=B9=FA=BC=CA=D3=F2=C3=FB=A3=AC=BD= =F6=CA=DB330=D4=AA/=C4=EA =CE=D2=C3=C7=B3=D0=C5=B524=D0=A1=CA=B1=CE=AA=C4=FA=B7=FE=CE=F1=A3=A1 =D7=C9=D1=AF=B5=E7=BB=B0:=A1=A10592-6026652=A1=A1/=A1=A18667174 / 8345= 012 / 8919334=A1=A1/=A1=A18375020 =B4=AB=D5=E6: 0592-6026652 =A1=A1QQ=D7=A8=CF=DF:=A1=A140327558 /=A1=A113531412=A1=A1/=A1=A1339256= 14 =A1=A1=D7=C9=D1=AF=D3=CA=CF=E4:=A1=A1zzweb@tom.com=A1=A1 =A1=A1 =D7=A3: =BA=C3=D4=CB=CC=EC=CC=EC=D3=D0=A1=A2=D0=D2=D4=CB=B3=A3=B0=E9=CB=E6= !!! =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=BA=E3=CB=D9=B4=EF=CD=F8=C2=E7 End of Rtspspec-bugs Digest --=_goobox-17433-1071288772-0001-2-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sat Dec 13 20:58:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19425 for ; Sat, 13 Dec 2003 20:58:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVLWL-0001O2-F2 for mmusic-archive@odin.ietf.org; Sat, 13 Dec 2003 20:58:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBE1w8XV005324 for mmusic-archive@odin.ietf.org; Sat, 13 Dec 2003 20:58:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVLWK-0001Nn-Fy for mmusic-web-archive@optimus.ietf.org; Sat, 13 Dec 2003 20:58:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19418 for ; Sat, 13 Dec 2003 20:58:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVLWI-0003gK-00 for mmusic-web-archive@ietf.org; Sat, 13 Dec 2003 20:58:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVLWH-0003gG-00 for mmusic-web-archive@ietf.org; Sat, 13 Dec 2003 20:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVLWD-0001N2-NM; Sat, 13 Dec 2003 20:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVLVz-0001Mg-8O for mmusic@optimus.ietf.org; Sat, 13 Dec 2003 20:57:47 -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 UAA19399 for ; Sat, 13 Dec 2003 20:57:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVLVw-0003fE-00 for mmusic@ietf.org; Sat, 13 Dec 2003 20:57:44 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AVLVw-0003eq-00 for mmusic@ietf.org; Sat, 13 Dec 2003 20:57:44 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2003 01:57:42 +0000 Received: from mbaugher-w2k07.cisco.com (sjc-vpn3-978.cisco.com [10.21.67.210]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBE1vBrY024664; Sat, 13 Dec 2003 17:57:12 -0800 (PST) Message-Id: <6.0.0.22.2.20031213175329.03c4fd80@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Sat, 13 Dec 2003 17:57:10 -0800 To: Magnus Westerlund From: Mark Baugher Cc: Flemming Andreasen , Dan Wing , IETF MMUSIC WG In-Reply-To: <3FD9B7EB.6000500@ericsson.com> References: <3FD9B7EB.6000500@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Re: Commetns on draft-ietf-mmusic-sdescriptions-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Magnus, My co-authors and I will address your issues prior to the next version of the I-D, which we should submit within the next several weeks. I have one comment, however, and that concerns your comments on multicast. We proposed to the last Wg meeting to drop multicast from the draft altogether and focus just on the unicast - as a divide and conquer strategy. I expect multicast functionality to be added in a subsequent draft when people are actively designing systems to support it. This proposal was posted in the WG minutes to this list and I have heard no dissent from anyone. cheers, Mark At 04:43 AM 12/12/2003, Magnus Westerlund wrote: >Hi, > >I have know read the draft and has thought about most of the open issues >that the draft presents and the discussion during the IETF meeting. There >are a couple of points below that, especially 5, that I believe requires >further discussion and study. > > >1. As a general thing I think authors should think about how the pages get >clipped by the pages. For improved readability one should move any new >sections, etc. that only gets a few line to the next page. One such >example is to start the table of contents on the first page, instead of on >the second. Another if the section 4 heading that are sole on the last >line of a page. > >2. The table contents may be a bit to detailed, I would think that it >would be acceptable to remove all third level items. > >3. The introduction contains a normative MUST. I don't think this is >really appropriate. Please find another place to locate this normative >text after the introduction. > >4. In the last paragraph of section 2, I think this section would benefit >of being split into two paragraphs. > >5. I think that one must look over the multicast cases and divide them >into different use cases. I think that removing all the multicast is a bad >choice as there are situation where it seems to work. I would start by >dividing the usage into scenarios where one can use the a=crypto successfully. > >- The one to many, using ASM case. This is a advertisement case. Only the >intended sender declares his SSRC/ROC/SEQ to ensure that all receivers >does not use the senders SSRC and causes a two time pad with it. As all >receivers are unsynchronized unless other mechanism is used, there might >happen SSRC collisions. However if you either don't encrypt the RTCP, >which is the only thing they will send, it is not a problem. Also if RTCP >encryption is used, it might be deemed acceptable with the low risk of two >time pads that exist. However this is clearly a security trade off. > >- The one to many, using SSM, as the receivers can't send to anybody else >there is no problem. If one uses unicast RTCP feedback, the same security >consideration regarding RTCP two time pads apply, however the distribution >of the offending packets will not be the same as for ASM use cases. > >- The multicast conference case, with a central session control instance. >As all participants speak only with the central control entity it can >ensure that SSRC, collision is avoided if the same key are used. However >in this case it is probably better to use individual master keys for each >sender. However there seems to be some need to fix the a=crypto syntax to >support this case. > >- The multicast conference, each sender announces there attributes >individually to each participant. In this case all should be required to >use individual master keys. Thus there is no risk for two time pads. > >As I see it with a few changes to the a=crypto attribute multicast can be >fixed. However there is need to flesh out the scenarios and ensure that >the signalling works for these. > >So as a conclusion there is need for more work in the multicast >environment. Also statement as the second bullet in 4.1.1.2 is not correct. > >6. void > >7. Section 5.1.1.1 the example line includes a extra "<" at the "lifetime" >parameter. > >8. Section 5.1.1.1: How does one know what type of key that is specified >in the key field. To my understanding there are a possibility for at least >three different levels of keys in SRTP. A top level master key, a master >key for a single SSRC, individual keys for streams. There is currently no >way of differentiating or requiring a key to be of a certain type. > >9. In section 5.1.1.1 there is a rule that the key length must be correct >for the signalled length. However a BASE64 encoded key|salt combination >may need some padding. So I assume that key lengths changing it to up to >the next base64 boundary is okay. > >10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about >how the number of packets are calculated and applies to. Is this the total >number of packets a master key can be used for, or does it applies to any >derived key, and when one of the derived keys reach this number it needs >to rekey? I don't think the text in section 5.3.1 really helps either, as >it makes it impossible for individual participants to actually calculate >how many packets that has been used by the master key. > >11. Section 5.2, I think this section could gain by an table that >tabulates the crypto suits and its major parameters for easy access >instead of the description. > >12. Section 5.3.1: The SRC parameter I think need to be better >clarified. If one gives a ROC/SEQ is given, it MUST be given in relation >to the SSRC for which it is valid. > >13. When it comes to offer answer for multicast, it must be made clear how >one uses SRC to ensure that a joining participant selects a SSRC that will >not collide. > >14. Section 5.3.1, what is an invalid SSRC? How do you know. > >15. How is the the usage of late binding and shared master key indicated, >to allow a receiver to determine what is used. > >16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key >derivation should be performed every packet. I would recommend to remove >this wrong motivation, and simply state it as being an exception. > >17. In 6.1.1.2 you have a restriction that from-to must only be used in >"recvonly", doesn't this depend on the scoping of these attributes. As >pointed out in point 10, the from to context is not clear. > >18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one? > >19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with >SSRC when common master key is used. > >20. In 6.1.2.1, Before the open issue, there is a statement that the is no >need for optional parameters. I think this is not, true or what is meant >with optional parameters must be clarified, there are certain use case >that definitely will require use of certain parameters. > >21. In 6.1.3.2 , there is text saying that session parameters shall be >ignored, I don't agree with that. > >22. In 6.1.3, In the paragraph after the bullets, one may get the >impression that multiple sources only are needed in multicast. That is not >true. Also in unicast a single end-point may need to use multiple SSRCs, >for example for retransmission. > >23. In 7.3, I think the RECOMMEND to use a key management protocol if not >carried in authenticated and encrypted transport format, should be a SHOULD. > >24, Section 7.3, Question, How does one know that the signalling over >network (b) even is encrypted. > >25. Section 8: "key-params" does not need to be recursively defined, the >second "key-params", needs only to be a "key-param" > >26. Section 8.1: key-method-ext, isn't this a "token"? I think restricting >the usage of other special characters then "_" is possibly to restricted. > >27. Section 8.2, is really decimal form for SSRC the best form. I would >recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 >bit binary identifier, not a number in its normal sense. > >28. Section 10.2.1, I think that you should review the standard IANA >registration levels in RFC 2434, I think that for the key method, it is >probably, "standards action" that is the right one. > >29. Section 10.2.2: I don't think that SRTP crypto suit registrations >needs only to take "inline" into consideration. I think it should say that >it should be defined in relation to applicable key-methods. I also think >that the IANA section should be a bit more explicit what really is required. > > >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 Sun Dec 14 17:05:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27311 for ; Sun, 14 Dec 2003 17:05:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeMM-0004f6-O8 for mmusic-archive@odin.ietf.org; Sun, 14 Dec 2003 17:05:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBEM56Ej017919 for mmusic-archive@odin.ietf.org; Sun, 14 Dec 2003 17:05:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeMM-0004ew-I4 for mmusic-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 17: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 RAA27306 for ; Sun, 14 Dec 2003 17:05:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVeMK-0004Gh-00 for mmusic-web-archive@ietf.org; Sun, 14 Dec 2003 17:05:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVeMJ-0004Ge-00 for mmusic-web-archive@ietf.org; Sun, 14 Dec 2003 17:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVeMI-0004eG-GX; Sun, 14 Dec 2003 17:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVcfA-00024I-30 for mmusic@optimus.ietf.org; Sun, 14 Dec 2003 15:16:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24283 for ; Sun, 14 Dec 2003 15:16:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVcf8-0002cf-00 for mmusic@ietf.org; Sun, 14 Dec 2003 15:16:22 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AVcel-0002cG-00 for mmusic@ietf.org; Sun, 14 Dec 2003 15:15:59 -0500 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Sun, 14 Dec 2003 12:13:42 -0800 Message-ID: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [MMUSIC] Re: Multiple 'm' lines with the same port number Thread-Index: AcPAqkdkQVjwyCYFSii78kcRsxxkQQB1Ji2A From: "Kumar, Rajesh" To: "Flemming Andreasen" , "Kevin Boyle" Cc: "Stephen Casner" , "Colin Perkins" , , "Mostafa, Mohamed" , "Abdelhamid, Hisham" , , Content-Transfer-Encoding: quoted-printable Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable AVT members, There was some confusion on this issue in the recent TIA TR.30.1 meeting in Orlando, Florida.=20 Could someone officially confirm or deny whether multiple "m=3D" lines with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) cannot be assigned the same port number? If they can be assigned the same port number, then it is possible to selectively associate RFC 2733 FEC with some payload types such as those that carry voice band data. Otherwise, there is a hole in SDP that does not permit selective, payload-specific declaration of FEC. I am aware of the fact that in RFC 2733 the use of and level of FEC is a transmitter prerogative and that a transmitter may choose to selectively utilize FEC based on payload type transmitted.=20 Thanks, Rajesh > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, December 12, 2003 4:21 AM > To: Kevin Boyle > Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; Mostafa, Mohamed; > Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number >=20 >=20 >=20 > Kevin Boyle wrote: >=20 > > > > > > All, > > > > Looking back at this email stream, one question remains outstanding in > > my mind: > > > > What if the two m=3D lines have the SAME media type? For instance: > > > > m=3Daudio 49232 RTP/AVP 18 > > m=3Dimage 49233 UDPTL t38 > > m=3Daudio 49232 RTP/AVP 100 > > a=3Drtpmap:100 PCMU/8000 > > a=3Dgpmd:100 vbd=3Dyes > > > > For some of the SDP-based protocols, the order of appearance is vital > > because it announces preference. >=20 > Only for the media formats within a given "m=3D" line. Multiple "m=3D" lines > indicates a set of simultaneous media streams; not alternatives. >=20 >=20 > > So, this shows preference for T.38 fax relay over PCMU VBD for fax, > > while utilizing G.729 for voice. As far as I can tell, this construct > > is allowed, since both m lines using the same port number use a media > > type of audio. > > > > Is my understanding correct? > > >=20 > Not quite. Each "m=3D" line corresponds to a separate media stream. Also, > the consensus of this discussion has been that you are *not* allowed to > use the same port for different media lines, regardless of whether they > share the same top-level MIME type or not. >=20 > -- Flemming >=20 > > > > Thanks, > > > > Kevin > > > > -----Original Message----- > > From: Stephen Casner [mailto:casner@acm.org] > > Sent: Friday, April 25, 2003 2:57 PM > > To: Rajesh Kumar > > Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > > paulej@cisco.com > > > > Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > Rajesh, > > > > > Is the use of multiple 'm=3D' lines with the same port number = within > > an > > > SDP descriptor permitted? > > > > Presuming that the multiple m=3D lines are all RTP/AVP, then doing = so > > causes all of the payload formats listed on the m=3D lines to become > > part of a single RTP session (unless they are distinguished by some > > other aspect of addressing). Section 5.2 of the RTP spec addresses > > NOT multiplexing different media in the same RTP session. > > > > > In SDP, as it is defined, all the media formats on an 'm=3D' line are > > of > > > the same media type (e.g. audio, image, text etc.). > > > > > > Now consider the case in which two RTP media formats can use a > > > destination port but are registered under different MIME types. For > > > example, text/t140 and audio/PCMU. In this case, there is no > > recourse > > > except to use multiple media lines with the same port number. For > > example: > > > > The "can use a destination port" is the tricky part. We may not > > agree. > > > > > m=3Daudio 49232 RTP/AVP 0 > > > m=3Dtext 49232 RTP/AVP 100 > > > a=3Drtpmap:100 t140 > > > > > > My thought is that although this is unsual, it is not proscribed by > > > SDP syntax in RFC 2327 or in its latest internet draft. > > > > I believe this is proscribed by section 5.2 of the RTP spec because > > these two media should not be multiplexed in one RTP session. > > > > My bet is that the real example you are thinking about is fax or modem > > over IP. We've been there before. > > > > -- Steve > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Sun Dec 14 23:28:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09102 for ; Sun, 14 Dec 2003 23:28:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVkL2-0007cw-6B for mmusic-archive@odin.ietf.org; Sun, 14 Dec 2003 23:28:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBF4S8Dn029314 for mmusic-archive@odin.ietf.org; Sun, 14 Dec 2003 23:28:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVkL2-0007cj-1v for mmusic-web-archive@optimus.ietf.org; Sun, 14 Dec 2003 23:28:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09099 for ; Sun, 14 Dec 2003 23:28:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVkL0-0002eF-00 for mmusic-web-archive@ietf.org; Sun, 14 Dec 2003 23:28:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVkKz-0002eB-00 for mmusic-web-archive@ietf.org; Sun, 14 Dec 2003 23:28:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVkKu-0007bz-LU; Sun, 14 Dec 2003 23:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVkKO-0007bC-7j for mmusic@optimus.ietf.org; Sun, 14 Dec 2003 23:27: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 XAA09072 for ; Sun, 14 Dec 2003 23:27:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVkKM-0002cI-00 for mmusic@ietf.org; Sun, 14 Dec 2003 23:27:26 -0500 Received: from rrcs-midsouth-24-199-215-41.biz.rr.com ([24.199.215.41] helo=paris.packetizer.org ident=system) by ietf-mx with esmtp (Exim 4.12) id 1AVkKL-0002cE-00 for mmusic@ietf.org; Sun, 14 Dec 2003 23:27:25 -0500 Received: from berlin (berlin.packetizer.org [192.168.1.4]) by paris.packetizer.org (8.12.5/8.12.5) with SMTP id hBF4RJBQ010974; Sun, 14 Dec 2003 23:27:19 -0500 Message-ID: <030901c3c2c3$ba7077d0$0401a8c0@berlin> From: "Paul E. Jones" To: "Flemming Andreasen" , "Kevin Boyle" Cc: "Stephen Casner" , "Rajesh Kumar" , "Colin Perkins" , , , , , References: <3FD9B2BE.1BFCE081@cisco.com> Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number Date: Sun, 14 Dec 2003 23:27:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Flemming, Perhaps Kevin should have offered slightly different syntax, using FID. Consider the following syntax: a=group:FID 1 2 3 m=audio 49232 RTP/AVP 18 a=mid:1 m=image 49233 UDPTL t38 a=mid:2 m=audio 49232 RTP/AVP 100 a=rtpmap:100 PCMU/8000 a=gpmd:100 vbd=yes a=mid:3 Is it still the consensus that, when using this syntax, the port numbers must be distinct? Paul ----- Original Message ----- From: "Flemming Andreasen" To: "Kevin Boyle" Cc: "Stephen Casner" ; "Rajesh Kumar" ; "Colin Perkins" ; ; ; ; ; Sent: Friday, December 12, 2003 7:21 AM Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > Kevin Boyle wrote: > > > > > > > All, > > > > Looking back at this email stream, one question remains outstanding in > > my mind: > > > > What if the two m= lines have the SAME media type? For instance: > > > > m=audio 49232 RTP/AVP 18 > > m=image 49233 UDPTL t38 > > m=audio 49232 RTP/AVP 100 > > a=rtpmap:100 PCMU/8000 > > a=gpmd:100 vbd=yes > > > > For some of the SDP-based protocols, the order of appearance is vital > > because it announces preference. > > Only for the media formats within a given "m=" line. Multiple "m=" lines > indicates a set of simultaneous media streams; not alternatives. > > > > So, this shows preference for T.38 fax relay over PCMU VBD for fax, > > while utilizing G.729 for voice. As far as I can tell, this construct > > is allowed, since both m lines using the same port number use a media > > type of audio. > > > > Is my understanding correct? > > > > Not quite. Each "m=" line corresponds to a separate media stream. Also, > the consensus of this discussion has been that you are *not* allowed to > use the same port for different media lines, regardless of whether they > share the same top-level MIME type or not. > > -- Flemming > > > > > Thanks, > > > > Kevin > > > > -----Original Message----- > > From: Stephen Casner [mailto:casner@acm.org] > > Sent: Friday, April 25, 2003 2:57 PM > > To: Rajesh Kumar > > Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > > paulej@cisco.com > > > > Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > Rajesh, > > > > > Is the use of multiple 'm=' lines with the same port number within > > an > > > SDP descriptor permitted? > > > > Presuming that the multiple m= lines are all RTP/AVP, then doing so > > causes all of the payload formats listed on the m= lines to become > > part of a single RTP session (unless they are distinguished by some > > other aspect of addressing). Section 5.2 of the RTP spec addresses > > NOT multiplexing different media in the same RTP session. > > > > > In SDP, as it is defined, all the media formats on an 'm=' line are > > of > > > the same media type (e.g. audio, image, text etc.). > > > > > > Now consider the case in which two RTP media formats can use a > > > destination port but are registered under different MIME types. For > > > example, text/t140 and audio/PCMU. In this case, there is no > > recourse > > > except to use multiple media lines with the same port number. For > > example: > > > > The "can use a destination port" is the tricky part. We may not > > agree. > > > > > m=audio 49232 RTP/AVP 0 > > > m=text 49232 RTP/AVP 100 > > > a=rtpmap:100 t140 > > > > > > My thought is that although this is unsual, it is not proscribed by > > > SDP syntax in RFC 2327 or in its latest internet draft. > > > > I believe this is proscribed by section 5.2 of the RTP spec because > > these two media should not be multiplexed in one RTP session. > > > > My bet is that the real example you are thinking about is fax or modem > > over IP. We've been there before. > > > > -- Steve > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 15 06:19:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03450 for ; Mon, 15 Dec 2003 06:19: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 1AVqkg-0006wx-LF for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 06:19:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFBJ2Af026698 for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 06:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVqkg-0006wX-Gk for mmusic-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 06:19: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 GAA03432 for ; Mon, 15 Dec 2003 06:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVqkX-00026Z-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 06:18:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVqjx-00025s-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 06:18:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVqjh-0006rL-Ef; Mon, 15 Dec 2003 06:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVqjQ-0006qs-Uh for mmusic@optimus.ietf.org; Mon, 15 Dec 2003 06:17:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03404 for ; Mon, 15 Dec 2003 06:17:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVqjA-00025P-00 for mmusic@ietf.org; Mon, 15 Dec 2003 06:17:28 -0500 Received: from swing.cefriel.it ([131.175.53.9]) by ietf-mx with esmtp (Exim 4.12) id 1AVqik-000259-00 for mmusic@ietf.org; Mon, 15 Dec 2003 06:17:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3C2FD.169461B5" Date: Mon, 15 Dec 2003 12:17:55 +0100 Message-ID: <6F5FB8313FE82C4EA10DA4DA40B9094901294F0E@swing.cefriel.it> Thread-Topic: RTSP mobility Thread-Index: AcPC/RYvjkTFMC3pR96tcbCSk5YNmQ== From: "Enrico Balatti" To: Subject: [MMUSIC] RTSP mobility Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C2FD.169461B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, in the European IST Project EVOLUTE (http://evolute.intranet.gr ) my organization have developed a solution for RTSP mobility. In our implementation we used as RTSP server (Darwin Streaming Server) and as RTSP client (MPEG4IP player). At the beginning we followed the paper : "Application Layer Mobility using SIP" written by H. Schulzrinne, E. Wedlund. The paper suggests the client issues a SETUP message after detecting that an handoff happens. In this SETUP message the client indicates its new IP address to which the RTP traffic must be delivered. This solution worked fine, but during the handoff the player window had become blue for few seconds and the clients had some problems in the re-synchronization with the incoming RTP streams. In order to overcome this bad behaviour we chose a different approach: when the handoff takes place, the client sends a PAUSE message, then it sends the new SETUP and final it restarts the streams with a PLAY message. In this way the player window freezes on the last received frame and after the handoff restarts from the subsequent frame. We know that this implementation has some faults: 1) We use the "destination" field of the transport header for indicating the new IP address used by the client, instead of the field "dest_addr" as the last RTSP draft and Magnus suggested. We are fully agree that no new headers or fields are needed in the RTSP protocol for this issue, because "dest_addr" fulfils all requirements. However we couldn't use it because the MPEG4IP version we have used doesn't support this field. 2) during the handoff we send 5 requests message for an Audio-video stream (1 PAUSE, 2 SETUP and 2 PLAY) and the server must send 5 response. This behaviour increases the handoff delay, however pausing the stream and freezing the player window on the last received frame has a good impact on the user perception of the service. Taking into account this experience we would like to propose a new approach for managing the RTSP mobility: 1) If the Service Provider would like to offer a RTSP service in a mobile environment where handoffs can happen, both client and server must support the "dest_addr" and "source_addr" field in the transport header.=20 2) the server detects the handoff if it receives a SETUP message for a running RTSP session and if this SETUP message contains in the "dest_addr" field an IP address different from the IP address the server is using in that RTSP session for sending RTP traffic. 3) In order to achieve a correct synchronization of the RTP streams after the handoff, the SETUP message should contains an indication of the last frame of the stream received before the handoff. To achieve this goal, we propose to extend the usage of the RTP-info also to the SETUP request and to set the indication of the last frame in the "range" or the "seq" field. 4) In order to reduce the number of requests sent during the handoff and not to make worse the user perception of the handoff, we propose the following state machine behaviour for both clients and servers:=20 a) when the clients detects the handoff, it pause all streams internally (without sending any PAUSE message), sends the SETUP message for each active stream and=20 after receiving the 200 OK from server, it plays again all the streams (without sending any PLAY message) b) when the server receives a SETUP message for a active RTSP session, it verify if this =20 SETUP is related to an handoff. If yes it pauses the RTP streams of the RTSP session =20 indicated in the message; it applies the changes in the RTP IP addresses and ports,=20 then it sends a 200 OK response (supposing that there aren't errors in the SETUP=20 message and in the following elaborations) and it restarts sending the RTP traffic. =20 Any comments and suggestions are welcomed. We will collect all the comments that will come out from the discussion and we will provide an draft on the RTSP mobility. Best Regards Enrico -------------------------------------------- Ing Enrico M. Balatti CEFRIEL - Politecnico di Milano ICT Center of Excellence For Research, Innovation,Education & industrial Labs partnership via Fucini 2, 20133 Milano (ITALY) voice: +39 0223954327 fax: +39 0223954527 e-mail: balatti@cefriel.it www.cefriel.it -------------------------------------------- ------_=_NextPart_001_01C3C2FD.169461B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RTSP mobility

Dear all,

in the European IST Project EVOLUTE (http://evolute.intranet.gr ) my organization have developed a solution for RTSP mobility. In = our implementation we used as RTSP server (Darwin Streaming Server) and as RTSP client (MPEG4IP player). At the beginning we followed the paper : = “Application Layer Mobility using SIP” written by H. = Schulzrinne, E. Wedlund. The paper suggests the client issues a SETUP = message after detecting that an handoff happens. In this SETUP message = the client indicates its new IP address to which the RTP traffic must be delivered. =

This solution worked fine, but during the handoff the player window = had become blue for few seconds and the clients had some problems = in  the re-synchronization with the incoming RTP streams. In order = to overcome this bad behaviour we chose a different approach: when the = handoff takes place, the client sends a PAUSE message, then it sends the = new SETUP and final it restarts the streams with a PLAY message. In this = way the player window freezes on the last received frame and after the = handoff restarts from the subsequent frame.

We know that this implementation has some faults:

1) We use the "destination" field of = the transport header for indicating the new IP address used by the client, = instead of the field "dest_addr" as the last RTSP draft and = Magnus suggested. We are fully agree that no new headers or fields are = needed in the RTSP protocol for this issue, because = "dest_addr" fulfils all requirements. However we couldn't use = it because the MPEG4IP version we have used doesn't support this = field.

2) during the handoff we send 5 requests message for an Audio-video = stream (1 PAUSE, 2 SETUP and 2 PLAY) and the server must send 5 = response. This behaviour increases the handoff delay, however pausing = the stream and freezing the player window on the last received frame has = a good impact on the user perception of the service.


Taking into account this experience we would like to propose a new = approach for managing the RTSP mobility:

1) If  the Service Provider would like to offer a RTSP service = in a mobile environment where handoffs can happen, both client and = server must support the "dest_addr" and = "source_addr" field in the transport header.

2) the server detects the handoff if it receives a SETUP message = for a running RTSP session and if this SETUP message contains in the  "dest_addr" = field an IP address different from the IP address the server is using in that RTSP = session for sending RTP traffic.

3) In order to achieve a correct synchronization of the RTP streams = after the handoff, the SETUP message should contains an indication of the last frame of the = stream received before the handoff. To achieve this goal, we propose = to extend the usage of = the RTP-info also to the SETUP request and to set the indication of the last frame in = the  = "range" or the "seq" field.

4) In order to reduce the number of requests sent during the = handoff and not to make worse the user perception of the handoff, we = propose the following state machine behaviour for both clients and = servers:

           a) = when the clients detects the handoff, it pause all streams internally = (without sending

           &n= bsp;  any PAUSE message), sends the SETUP message for each active = stream and

           &n= bsp;   after receiving the 200 OK from server, it plays again = all the streams (without

           &n= bsp;   sending any PLAY message)

           b) = when the server receives a SETUP message for a active RTSP session, it = verify if this 

           &n= bsp;  SETUP is related to an handoff. If yes it pauses the RTP = streams of the RTSP session   

           &n= bsp;  indicated in the message; it applies the changes in the RTP = IP addresses and ports,

           &n= bsp;  then it sends a 200 OK response (supposing that there aren't = errors in the SETUP

           &n= bsp;  message and in the following elaborations) and it restarts = sending the RTP traffic.

 

Any comments and suggestions are welcomed.

We will collect all the comments that will come out from the = discussion and we will provide an draft on the RTSP = mobility.

Best Regards

Enrico



--------------------------------------------

Ing Enrico M. Balatti

CEFRIEL - Politecnico di Milano

ICT Center of Excellence For Research,

Innovation,Education & industrial Labs

partnership

via Fucini 2, 20133 Milano (ITALY)

voice: +39 0223954327 fax: +39 0223954527

e-mail: balatti@cefriel.it www.cefriel.it

--------------------------------------------

------_=_NextPart_001_01C3C2FD.169461B5-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 15 09:48:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10257 for ; Mon, 15 Dec 2003 09:48: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 1AVu0w-0006ml-Sh for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 09:48:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFEm2mN026079 for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 09:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu0w-0006mY-Nq for mmusic-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 09:48: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 JAA10214 for ; Mon, 15 Dec 2003 09:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVu0u-0005pH-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 09:48:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVu0u-0005pE-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 09:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu0v-0006lz-4N; Mon, 15 Dec 2003 09:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVu0c-0006lW-QK for mmusic@optimus.ietf.org; Mon, 15 Dec 2003 09:47:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10200 for ; Mon, 15 Dec 2003 09:47:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVu0a-0005ox-00 for mmusic@ietf.org; Mon, 15 Dec 2003 09:47:40 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AVu0a-0005oB-00 for mmusic@ietf.org; Mon, 15 Dec 2003 09:47:40 -0500 Received: from cisco.com (sjc-vpn4-133.cisco.com [10.21.80.133]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBFEl4rX028565; Mon, 15 Dec 2003 06:47:05 -0800 (PST) Message-ID: <3FDDC968.EF4A5D12@cisco.com> Date: Mon, 15 Dec 2003 09:47:04 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Paul E. Jones" CC: Kevin Boyle , Stephen Casner , Rajesh Kumar , Colin Perkins , mmusic@ietf.org, mmostafa@cisco.com, hisham@cisco.com, mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <3FD9B2BE.1BFCE081@cisco.com> <030901c3c2c3$ba7077d0$0401a8c0@berlin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Paul E. Jones" wrote: > Flemming, > > Perhaps Kevin should have offered slightly different syntax, using FID. > Consider the following syntax: > > a=group:FID 1 2 3 > m=audio 49232 RTP/AVP 18 > a=mid:1 > m=image 49233 UDPTL t38 > a=mid:2 > m=audio 49232 RTP/AVP 100 > a=rtpmap:100 PCMU/8000 > a=gpmd:100 vbd=yes > a=mid:3 > > Is it still the consensus that, when using this syntax, the port numbers > must be distinct? > Yes. RFC 3388 is very clear about this point in Section 7.5.3: "FID MUST NOT be used to group "m" lines with the same IP address/port. " -- Flemming > > Paul > > ----- Original Message ----- > From: "Flemming Andreasen" > To: "Kevin Boyle" > Cc: "Stephen Casner" ; "Rajesh Kumar" ; > "Colin Perkins" ; ; ; > ; ; > Sent: Friday, December 12, 2003 7:21 AM > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > > > > Kevin Boyle wrote: > > > > > > > > > > > All, > > > > > > Looking back at this email stream, one question remains outstanding in > > > my mind: > > > > > > What if the two m= lines have the SAME media type? For instance: > > > > > > m=audio 49232 RTP/AVP 18 > > > m=image 49233 UDPTL t38 > > > m=audio 49232 RTP/AVP 100 > > > a=rtpmap:100 PCMU/8000 > > > a=gpmd:100 vbd=yes > > > > > > For some of the SDP-based protocols, the order of appearance is vital > > > because it announces preference. > > > > Only for the media formats within a given "m=" line. Multiple "m=" lines > > indicates a set of simultaneous media streams; not alternatives. > > > > > > > So, this shows preference for T.38 fax relay over PCMU VBD for fax, > > > while utilizing G.729 for voice. As far as I can tell, this construct > > > is allowed, since both m lines using the same port number use a media > > > type of audio. > > > > > > Is my understanding correct? > > > > > > > Not quite. Each "m=" line corresponds to a separate media stream. Also, > > the consensus of this discussion has been that you are *not* allowed to > > use the same port for different media lines, regardless of whether they > > share the same top-level MIME type or not. > > > > -- Flemming > > > > > > > > Thanks, > > > > > > Kevin > > > > > > -----Original Message----- > > > From: Stephen Casner [mailto:casner@acm.org] > > > Sent: Friday, April 25, 2003 2:57 PM > > > To: Rajesh Kumar > > > Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > > > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > > > paulej@cisco.com > > > > > > Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > > > Rajesh, > > > > > > > Is the use of multiple 'm=' lines with the same port number within > > > an > > > > SDP descriptor permitted? > > > > > > Presuming that the multiple m= lines are all RTP/AVP, then doing so > > > causes all of the payload formats listed on the m= lines to become > > > part of a single RTP session (unless they are distinguished by some > > > other aspect of addressing). Section 5.2 of the RTP spec addresses > > > NOT multiplexing different media in the same RTP session. > > > > > > > In SDP, as it is defined, all the media formats on an 'm=' line are > > > of > > > > the same media type (e.g. audio, image, text etc.). > > > > > > > > Now consider the case in which two RTP media formats can use a > > > > destination port but are registered under different MIME types. For > > > > example, text/t140 and audio/PCMU. In this case, there is no > > > recourse > > > > except to use multiple media lines with the same port number. For > > > example: > > > > > > The "can use a destination port" is the tricky part. We may not > > > agree. > > > > > > > m=audio 49232 RTP/AVP 0 > > > > m=text 49232 RTP/AVP 100 > > > > a=rtpmap:100 t140 > > > > > > > > My thought is that although this is unsual, it is not proscribed by > > > > SDP syntax in RFC 2327 or in its latest internet draft. > > > > > > I believe this is proscribed by section 5.2 of the RTP spec because > > > these two media should not be multiplexed in one RTP session. > > > > > > My bet is that the real example you are thinking about is fax or modem > > > over IP. We've been there before. > > > > > > -- Steve > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 15 11:20:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15382 for ; Mon, 15 Dec 2003 11:20:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvS6-0001vF-Lg for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 11:20:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFGKA8l007383 for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 11:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvS5-0001v0-OS for mmusic-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 11:20:09 -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 LAA15377 for ; Mon, 15 Dec 2003 11:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvS4-00001C-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 11:20:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVvS4-000019-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 11:20:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvS1-0001uM-0D; Mon, 15 Dec 2003 11:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVvRN-0001tE-2n for mmusic@optimus.ietf.org; Mon, 15 Dec 2003 11:19:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15344 for ; Mon, 15 Dec 2003 11:19:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVvRM-00000J-00 for mmusic@ietf.org; Mon, 15 Dec 2003 11:19:24 -0500 Received: from breeze.research.telcordia.com ([192.4.6.9]) by ietf-mx with esmtp (Exim 4.12) id 1AVvRL-0007nC-00 for mmusic@ietf.org; Mon, 15 Dec 2003 11:19:23 -0500 Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.12.8/8.12.1) with ESMTP id hBFGIkn6009334; Mon, 15 Dec 2003 11:18:47 -0500 (EST) Message-Id: <200312151618.hBFGIkn6009334@breeze.research.telcordia.com> To: "Enrico Balatti" cc: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP mobility In-reply-to: Your message of "Mon, 15 Dec 2003 12:17:55 +0100." <6F5FB8313FE82C4EA10DA4DA40B9094901294F0E@swing.cefriel.it> Date: Mon, 15 Dec 2003 11:18:46 -0500 From: Ashutosh Dutta 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: , Enrico, I guess what we are looking for is a solution for supporting fast-handoff for redirecting the media after the IP address is obtained on the mobile which of course has its own delay based on the type of address acquisition (DHCP/PPP). Limiting the number of signaling messages will definitely help the handoff related loss, or redirecting the transient media will help a bit also if one plans to use the existing methodology as it is. Redirecting the transient data can be done in several ways. Thanks Ashutosh > Any comments and suggestions are welcomed. > We will collect all the comments that will come out from the discussion > and we will provide an draft on the RTSP mobility. > > Best Regards > > Enrico > > > > -------------------------------------------- > Ing Enrico M. Balatti > CEFRIEL - Politecnico di Milano > ICT Center of Excellence For Research, > Innovation,Education & industrial Labs > partnership > via Fucini 2, 20133 Milano (ITALY) > voice: +39 0223954327 fax: +39 0223954527 > e-mail: balatti@cefriel.it www.cefriel.it > -------------------------------------------- > > > > ------_=_NextPart_001_01C3C2FD.169461B5 > Content-Type: text/html; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > charset=3Dus-ascii"> > 6.0.6249.1"> > RTSP mobility > > > > >

New">Dear all,

> >

New">in the European IST Project EVOLUTE ( LANG=3D"it"> LANG=3D"it"> LANG=3D"en-gb"> New">http://evolute.intranet.gr LANG=3D"it"> LANG=3D"it"> New"> ) my organization have developed a solution for RTSP mobility. In = > our implementation we used as RTSP server LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">(D LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">arwin Streaming Server LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">) LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New"> and as RTSP client LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">( LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">MPEG4IP LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New"> LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">player LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">) LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">. At the beginning we followed the paper : = > “Application Layer Mobility using SIP” written by H. = > Schulzrinne, E. Wedlund. The paper suggests the client issues a SETUP = > message after detecting that an handoff happens. In this SETUP message = > the client indicates LANG=3D"it"> New"> it LANG=3D"it"> New">s new IP address to which the RTP traffic must be delivered. = >

> >

New">This solution worked fine, but during the handoff the player window = > had become blue for few seconds and the clients had some problems = > in  the re-synchronization with the incoming RTP streams. In order = > to overcome this bad behaviour we chose a different approach: when the = > handoff takes place, the client sends a PAUSE message, then it sends the = > new SETUP and final it restarts the streams with a PLAY message. In this = > way the player window freezes on the last received frame and after the = > handoff restarts from the subsequent frame.

> >

New">We know that this implementation has some faults:

> >

New">1) We use the "destination" field of = > the LANG=3D"en-gb"> New">transport LANG=3D"it"> New"> header for indicating the new IP address used by the client, = > instead of the field "dest_addr" as the last RTSP draft and = > Magnus suggested. We are fully agree that no new headers or fields are = > needed in the RTSP protocol for this issue, because = > "dest_addr" fulfils all requirements. However we couldn't use = > it because the MPEG4IP version we have used doesn't support this = > field.

> >

New">2) during the handoff we send 5 requests message for an Audio-video = > stream (1 PAUSE, 2 SETUP and 2 PLAY) and the server must send 5 = > response. This behaviour increases the handoff delay, however pausing = > the stream and freezing the player window on the last received frame has = > a good impact on the user perception of the service.

>
> >

New">Taking into account this experience we would like to propose a new = > approach for managing the RTSP mobility:

> >

New">1) If  the Service Provider would like to offer a RTSP service = > in a mobile environment where handoffs can happen, both client and = > server must support the "dest_addr" and = > "source_addr" field in the LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">transport header LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">.

> >

New">2) the server detects the handoff if it receives a SETUP message = > for a running RTSP session LANG=3D"it"> New"> and if LANG=3D"it"> New">this SETUP message contain LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">s LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New"> in the  "dest_addr" = > field LANG=3D"it"> New"> an IP address LANG=3D"it"> New"> different from the IP address the server is using in that RTSP = > session for sending RTP traffic.

> >

New">3) In order to achieve a correct synchronization of the RTP streams = > after the handoff, the SETUP message should contain LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">s an indication of the last frame of the = > stre LANG=3D"it"> New">am received before the handoff. LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New">To achieve this goal, we propose = > t LANG=3D"en-gb">o extend the usage of = > the RTP-info also to LANG=3D"it"> New">the SETUP LANG=3D"it"> New">request and to set the indication of the last frame in = > th LANG=3D"en-gb">e LANG=3D"it"> SIZE=3D2 FACE=3D"Courier New"> LANG=3D"it"> LANG=3D"en-gb">  = > "range" or LANG=3D"it"> New">the LANG=3D"it"> New"> "seq" field LANG=3D"it"> New">.

> >

New">4) In order to reduce the number of requests sent during the = > handoff and not to make worse the user perception of the handoff, we = > propose the following state machine behaviour for both clients and = > servers:

> >

New">           a) = > when the clients detects the handoff, it pause all streams internally = > (without sending

> >

New">           &n= > bsp;  any PAUSE message), sends the SETUP message for each active = > stream and

> >

New">           &n= > bsp;   after receiving the 200 OK from server, it plays again = > all the streams (without

> >

New">           &n= > bsp;   sending any PLAY message)

> >

New">           b) = > when the server receives a SETUP message for a active RTSP session, it = > verify if this 

> >

New">           &n= > bsp;  SETUP is related to an handoff. If yes it pauses the RTP = > streams of the RTSP session   

> >

New">           &n= > bsp;  indicated in the message; it applies the changes in the RTP = > IP addresses and ports,

> >

New">           &n= > bsp;  then it sends a 200 OK response (supposing that there aren't = > errors in the SETUP

> >

New">           &n= > bsp;  message and in the following elaborations) and it restarts = > sending the RTP traffic.

> >

New"> 

> >

New">Any comments and suggestions are welcomed.

> >

New">We will collect all the comments that will come out from the = > discussion and we will provide an draft on the RTSP = > mobility.

> >

New">Best Regards

> >

New">Enrico

>
>
> >

LANG=3D"it-it"> New">--------------------------------------------

> >

New">Ing Enrico M. Balatti

> >

New">CEFRIEL - Politecnico di Milano

> >

New">ICT Center of Excellence For Research,

> >

New">Innovation,Education & industrial Labs

> >

New">partnership

> >

New">via Fucini 2, 20133 Milano (ITALY)

> >

New">voice: +39 0223954327 fax: +39 0223954527

> >

New">e-mail: balatti@cefriel.it www.cefriel.it

> >

New">--------------------------------------------

> >

> > > > ------_=_NextPart_001_01C3C2FD.169461B5-- > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic Ashutosh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 15 15:30:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26179 for ; Mon, 15 Dec 2003 15:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzM3-0005H9-6u for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 15:30:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBFKUBp0020275 for mmusic-archive@odin.ietf.org; Mon, 15 Dec 2003 15:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzM3-0005Gw-0y for mmusic-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 15:30:11 -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 PAA26129 for ; Mon, 15 Dec 2003 15:30:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVzM0-0005JT-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 15:30:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AVzLy-0005JC-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 15:30:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AVzLx-0005J7-00 for mmusic-web-archive@ietf.org; Mon, 15 Dec 2003 15:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzLv-0005EU-5f; Mon, 15 Dec 2003 15:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVzL6-0005DC-A1 for mmusic@optimus.ietf.org; Mon, 15 Dec 2003 15:29:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26019; Mon, 15 Dec 2003 15:29:10 -0500 (EST) Message-Id: <200312152029.PAA26019@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 15 Dec 2003 15:29:09 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-anat-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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,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 : The Alternative Network Address Types Semantics for the Session Description Protocol Grouping Framework Author(s) : G. Camarillo Filename : draft-ietf-mmusic-anat-00.txt Pages : 7 Date : 2003-12-15 This document defines the Alternative Network Address Types (ANAT) semantics for the SDP grouping framework. The ANAT semantics allow offering alternative types of network addresses to establish a particular media stream. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-anat-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-anat-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-anat-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-15150335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-anat-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-anat-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-15150335.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 Dec 16 14:29:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28513 for ; Tue, 16 Dec 2003 14:29:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKsJ-0001Ao-4c for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 14:28:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGJStFK004504 for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 14:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKsI-0001AZ-Vr for mmusic-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 14:28:55 -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 OAA28503 for ; Tue, 16 Dec 2003 14:28:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWKsB-00077V-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 14:28:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWKrl-000773-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 14:28:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWKrk-000762-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 14:28:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKrR-00015h-7b; Tue, 16 Dec 2003 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWKrD-00015P-Gd for mmusic@optimus.ietf.org; Tue, 16 Dec 2003 14:27:47 -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 OAA28459 for ; Tue, 16 Dec 2003 14:27:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWKqy-00074b-00 for mmusic@ietf.org; Tue, 16 Dec 2003 14:27:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWKqZ-000743-00 for mmusic@ietf.org; Tue, 16 Dec 2003 14:27:07 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AWKqY-00072F-00 for mmusic@ietf.org; Tue, 16 Dec 2003 14:27:06 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61128 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AWKpc-00040N-00; Tue, 16 Dec 2003 19:26:08 +0000 Date: Mon, 15 Dec 2003 15:34:18 +0000 From: Colin Perkins To: Pekka Pessi Cc: mmusic@ietf.org Subject: Re: [mmusic] Inclusion of media type = "text" in SDP Message-Id: <20031215153418.3fcb0bbf.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8 (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.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit --> Pekka Pessi writes: > Colin Perkins writes: > >> ; sub-rules of 'm=' > >> media = token > >> ;typically "audio", "video", "text", > >> "application" > >> ;or "data" > > >These will be in draft-ietf-mmusic-sdp-new-16. > > At the same time, it could be a god idea to add also the "message" > media. Can you suggest text to update the ABNF, the Media Announcement section (Section 5.14), and the IANA considerations section? Also, please give a reference to existing use of the "message" media type, to be included in the draft. Thanks, Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 16 16:29:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08023 for ; Tue, 16 Dec 2003 16:29:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMk7-00076G-Dl for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 16:28:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGLSZpj027285 for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 16:28:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMk7-000760-9s for mmusic-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:28: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 QAA07951 for ; Tue, 16 Dec 2003 16:28:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMk5-0005Hi-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 16:28:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMjk-0005Eo-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 16:28:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMjk-0005Db-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 16:28:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMjZ-00072K-CZ; Tue, 16 Dec 2003 16:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMik-00071f-0G for mmusic@optimus.ietf.org; Tue, 16 Dec 2003 16:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07778 for ; Tue, 16 Dec 2003 16:27:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMid-00058E-00 for mmusic@ietf.org; Tue, 16 Dec 2003 16:27:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMiC-00057V-00 for mmusic@ietf.org; Tue, 16 Dec 2003 16:26:37 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AWMiB-00056K-00 for mmusic@ietf.org; Tue, 16 Dec 2003 16:26:35 -0500 Received: from cisco.com (sjc-vpn4-75.cisco.com [10.21.80.75]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hBGLPqiN023547; Tue, 16 Dec 2003 13:25:52 -0800 (PST) Message-ID: <3FDF785F.2E9640AB@cisco.com> Date: Tue, 16 Dec 2003 16:25:51 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: Mark Baugher , Dan Wing , IETF MMUSIC WG Subject: Re: [MMUSIC] Commetns on draft-ietf-mmusic-sdescriptions-02.txt References: <3FD9B7EB.6000500@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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,RISK_FREE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Magnus Thank you very much for your detailed review - please see below for answers. To make it a easier to track any further discussion that might be needed on any of these points, I'd suggest that they be broken out in separate threads Magnus Westerlund wrote: > Hi, > > I have know read the draft and has thought about most of the open issues > that the draft presents and the discussion during the IETF meeting. > There are a couple of points below that, especially 5, that I believe > requires further discussion and study. > > 1. As a general thing I think authors should think about how the pages > get clipped by the pages. For improved readability one should move any > new sections, etc. that only gets a few line to the next page. One such > example is to start the table of contents on the first page, instead of > on the second. Another if the section 4 heading that are sole on the > last line of a page. > OK > > 2. The table contents may be a bit to detailed, I would think that it > would be acceptable to remove all third level items. > I prefer keeping third level items. > > 3. The introduction contains a normative MUST. I don't think this is > really appropriate. Please find another place to locate this normative > text after the introduction. > We'll make it a lower-case must (corresponding MUSTs found in Section 10) > > 4. In the last paragraph of section 2, I think this section would > benefit of being split into two paragraphs. > OK (I assume split it right before "In Section 3, we...") > > 5. I think that one must look over the multicast cases and divide them > into different use cases. I think that removing all the multicast is a > bad choice as there are situation where it seems to work. I would start > by dividing the usage into scenarios where one can use the a=crypto > successfully. > > - The one to many, using ASM case. This is a advertisement case. Only > the intended sender declares his SSRC/ROC/SEQ to ensure that all > receivers does not use the senders SSRC and causes a two time pad with > it. As all receivers are unsynchronized unless other mechanism is used, > there might happen SSRC collisions. However if you either don't encrypt > the RTCP, which is the only thing they will send, it is not a problem. > Also if RTCP encryption is used, it might be deemed acceptable with the > low risk of two time pads that exist. However this is clearly a security > trade off. > > - The one to many, using SSM, as the receivers can't send to anybody > else there is no problem. If one uses unicast RTCP feedback, the same > security consideration regarding RTCP two time pads apply, however the > distribution of the offending packets will not be the same as for ASM > use cases. > > - The multicast conference case, with a central session control > instance. As all participants speak only with the central control entity > it can ensure that SSRC, collision is avoided if the same key are used. > However in this case it is probably better to use individual master keys > for each sender. However there seems to be some need to fix the a=crypto > syntax to support this case. > > - The multicast conference, each sender announces there attributes > individually to each participant. In this case all should be required to > use individual master keys. Thus there is no risk for two time pads. > > As I see it with a few changes to the a=crypto attribute multicast can > be fixed. However there is need to flesh out the scenarios and ensure > that the signalling works for these. > > So as a conclusion there is need for more work in the multicast > environment. Also statement as the second bullet in 4.1.1.2 is not correct. > I agree that if we were to address multicast in this document, then we would need to identify the different multicast cases and address them one by one. The author team started doing that before publishing this version, but did not find the task to be as simple as you suggest. We saw several problems and complications related to multicast (e.g. the "use" parameter, hierarchical/layered encoding schemes, SSRC "collissions" in the SDP). We felt (and feel) fairly confident that inclusion of multicast support in this document will result in a significant delay in progressing this work, and since there is a real-life need to move this along, we proposed to leave multicast for further study. There was consensus in the meeting for that, and until now, there hasn't been any objections on the mailing list either. I still favor leaving multicast support for further study. > > 6. void > > 7. Section 5.1.1.1 the example line includes a extra "<" at the > "lifetime" parameter. > Got it. > > 8. Section 5.1.1.1: How does one know what type of key that is specified > in the key field. To my understanding there are a possibility for at > least three different levels of keys in SRTP. A top level master key, a > master key for a single SSRC, individual keys for streams. There is > currently no way of differentiating or requiring a key to be of a > certain type. > I'm not sure what the two different master keys you are referring to are - AFAIK all keys for SRTP are derived from one random number, the SRTP master key. Section 5.1.1.1 does explicitly talk about "master keys" (not session keys), but if there are specific places where you think it is unclear and/or you have some suggested text, please let me know. > > 9. In section 5.1.1.1 there is a rule that the key length must be > correct for the signalled length. However a BASE64 encoded key|salt > combination may need some padding. So I assume that key lengths changing > it to up to the next base64 boundary is okay. > Yes - good point. > > 10. Section 5.1.1.1: The lifetime parameter "from-to" is not clear about > how the number of packets are calculated and applies to. Is this the > total number of packets a master key can be used for, or does it applies > to any derived key, and when one of the derived keys reach this number > it needs to rekey? I don't think the text in section 5.3.1 really helps > either, as it makes it impossible for individual participants to > actually calculate how many packets that has been used by the master key. > It is simply intended to be the <"From", "To"> parameter as described in srtp-09: "* <"From", "To"> values, specifying the lifetime for a master key, expressed in terms of the two 48-bit index values inside whose range (including the range end-points) the master key is valid. For the use of , see Section 8.1.1. <"From", "To"> is an alternative to the MKI and assumes that a master key is in one-to- one correspondence with the SRTP session key on which the <"From", "To"> range is defined." Perhaps we need to make that clearer or is there more to it than that ? > 11. Section 5.2, I think this section could gain by an table that > tabulates the crypto suits and its major parameters for easy access > instead of the description. > I like the descriptive text we have in there but see your point as well. How about adding the table as an easy reference/overview ? > > 12. Section 5.3.1: The SRC parameter I think need to be better > clarified. If one gives a ROC/SEQ is given, it MUST be given in > relation to the SSRC for which it is valid. > OK > > 13. When it comes to offer answer for multicast, it must be made clear > how one uses SRC to ensure that a joining participant selects a SSRC > that will not collide. > That is one of the problems we faced with multicast which is why we want to leave multicast support for further study. > > 14. Section 5.3.1, what is an invalid SSRC? How do you know. > We'll clarify. > > 15. How is the the usage of late binding and shared master key > indicated, to allow a receiver to determine what is used. > Not sure I understand the question. When late binding is used, you are just not being informed about the SSRC for the crypto context in the SDP but rather you determine based on the packet received. What is unique about shared master keys in this context as opposed to the non-late-binding case ? > > 16. Section 5.3.2, It says that 2^0 is 1, as this being a frequency, key > derivation should be performed every packet. I would recommend to remove > this wrong motivation, and simply state it as being an exception. > OK > > 17. In 6.1.1.2 you have a restriction that from-to must only be used in > "recvonly", doesn't this depend on the scoping of these attributes. As > pointed out in point 10, the from to context is not clear. > 6.1.1.2 is about multicast which we want to leave for further study. > > 18. In 6.1.2.1, isn't the accepting of a crypto line, one and only one? > I don't follow - can you point me to the specific text ? > > 19. In 6.1.2.1 Shouldn't there be a rule requiring the use of SRC with > SSRC when common master key is used. > Not necessarily - if you have centralized SSRC allocation you wouldn't need this. However, I agree that a warning would be appropriate here. > > 20. In 6.1.2.1, Before the open issue, there is a statement that the is > no need for optional parameters. I think this is not, true or what is > meant with optional parameters must be clarified, there are certain use > case that definitely will require use of certain parameters. > (Section 6.1.2.2 I presume). This is a multicast section which should be left for further study. > > 21. In 6.1.3.2 , there is text saying that session parameters shall be > ignored, I don't agree with that. > This is a multicast section which should be left for further study. > > 22. In 6.1.3, In the paragraph after the bullets, one may get the > impression that multiple sources only are needed in multicast. That is > not true. Also in unicast a single end-point may need to use multiple > SSRCs, for example for retransmission. > Right. We'll start a separate thread on this issue. > > 23. In 7.3, I think the RECOMMEND to use a key management protocol if > not carried in authenticated and encrypted transport format, should be a > SHOULD. > SHOULD and RECOMMENDED are synonymous per RFC 2119. > > 24, Section 7.3, Question, How does one know that the signalling over > network (b) even is encrypted. > That depends on the signaling protocol. I guess you can never really know for sure, but at least if you are using SIP, then use of SIPS-URIs will "ensure" this. > > 25. Section 8: "key-params" does not need to be recursively defined, the > second "key-params", needs only to be a "key-param" > Fixed. > > 26. Section 8.1: key-method-ext, isn't this a "token"? I think > restricting the usage of other special characters then "_" is possibly > to restricted. > A name is a name. We can change it to token if you want, but I don't see how this is too restrictive (however I now found an error in the key-info production, so thanks :-). > > 27. Section 8.2, is really decimal form for SSRC the best form. I would > recommend a format in hex instead, e.g. 8*HEX, as an SSRC really is a 32 > bit binary identifier, not a number in its normal sense. > A matter of style I guess. This is probably a silly argument, but I'm a bit worried about using decimal every else and then all of a sudden hex. If we do it, then what do you think about prefixing it with an "x" ? > > 28. Section 10.2.1, I think that you should review the standard IANA > registration levels in RFC 2434, I think that for the key method, it is > probably, "standards action" that is the right one. > Ok - is that the consensus of everybody (fine with me) ? > > 29. Section 10.2.2: I don't think that SRTP crypto suit registrations > needs only to take "inline" into consideration. I think it should say > that it should be defined in relation to applicable key-methods. I also > think that the IANA section should be a bit more explicit what really is > required. > OK Again, thanks for the comments. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 16 18:24:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14086 for ; Tue, 16 Dec 2003 18:24: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 1AWOXr-0003bJ-K9 for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 18:24:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNO3Ot013837 for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 18:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOXr-0003b6-Fs for mmusic-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:24: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 SAA14073 for ; Tue, 16 Dec 2003 18:23:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOXo-0001ua-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:24:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOXn-0001uT-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:23:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWOXm-0001uQ-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOXo-0003aU-W4; Tue, 16 Dec 2003 18:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AVtub-0006Cv-5e for mmusic@optimus.ietf.org; Mon, 15 Dec 2003 09:41: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 JAA09894 for ; Mon, 15 Dec 2003 09:41:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AVtuZ-0005gp-00 for mmusic@ietf.org; Mon, 15 Dec 2003 09:41:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AVtuY-0005fd-00 for mmusic@ietf.org; Mon, 15 Dec 2003 09:41:26 -0500 Received: from cisco.com (sjc-vpn4-133.cisco.com [10.21.80.133]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBFEeprX025034; Mon, 15 Dec 2003 06:40:51 -0800 (PST) Message-ID: <3FDDC7F2.4B96D69@cisco.com> Date: Mon, 15 Dec 2003 09:40:50 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Kumar, Rajesh" CC: Kevin Boyle , Stephen Casner , Colin Perkins , mmusic@ietf.org, "Mostafa, Mohamed" , "Abdelhamid, Hisham" , mgarakan@cisco.com, paulej@cisco.com Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number References: <6677B3346233B94EBB11C060935101200290817B@vtg-um-e2k1.sj21ad.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit "Kumar, Rajesh" wrote: > AVT members, > > There was some confusion on this issue in the recent TIA TR.30.1 meeting > in Orlando, Florida. > > Could someone officially confirm or deny whether multiple "m=" lines > with the SAME media type (e.g. "audio") and protocol (e.g. RTP/AVP) > cannot be assigned the same port number? The consensus of this discussion is that is that they cannot (assuming they use the same IP address). -- Flemming > If they can be assigned the > same port number, then it is possible to selectively associate RFC 2733 > FEC with some payload types such as those that carry voice band data. > Otherwise, there is a hole in SDP that does not permit selective, > payload-specific declaration of FEC. I am aware of the fact that in RFC > 2733 the use of and level of FEC is a transmitter prerogative and that a > transmitter may choose to selectively utilize FEC based on payload type > transmitted. > > Thanks, > > Rajesh > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Friday, December 12, 2003 4:21 AM > > To: Kevin Boyle > > Cc: Stephen Casner; Kumar, Rajesh; Colin Perkins; mmusic@ietf.org; > Mostafa, Mohamed; > > Abdelhamid, Hisham; mgarakan@cisco.com; paulej@cisco.com > > Subject: Re: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > > > > > Kevin Boyle wrote: > > > > > > > > > > > All, > > > > > > Looking back at this email stream, one question remains outstanding > in > > > my mind: > > > > > > What if the two m= lines have the SAME media type? For instance: > > > > > > m=audio 49232 RTP/AVP 18 > > > m=image 49233 UDPTL t38 > > > m=audio 49232 RTP/AVP 100 > > > a=rtpmap:100 PCMU/8000 > > > a=gpmd:100 vbd=yes > > > > > > For some of the SDP-based protocols, the order of appearance is > vital > > > because it announces preference. > > > > Only for the media formats within a given "m=" line. Multiple "m=" > lines > > indicates a set of simultaneous media streams; not alternatives. > > > > > > > So, this shows preference for T.38 fax relay over PCMU VBD for fax, > > > while utilizing G.729 for voice. As far as I can tell, this > construct > > > is allowed, since both m lines using the same port number use a > media > > > type of audio. > > > > > > Is my understanding correct? > > > > > > > Not quite. Each "m=" line corresponds to a separate media stream. > Also, > > the consensus of this discussion has been that you are *not* allowed > to > > use the same port for different media lines, regardless of whether > they > > share the same top-level MIME type or not. > > > > -- Flemming > > > > > > > > Thanks, > > > > > > Kevin > > > > > > -----Original Message----- > > > From: Stephen Casner [mailto:casner@acm.org] > > > Sent: Friday, April 25, 2003 2:57 PM > > > To: Rajesh Kumar > > > Cc: Colin Perkins; mmusic@ietf.org; flemming Andreasen; > > > mmostafa@cisco.com; hisham@cisco.com; mgarakan@cisco.com; > > > paulej@cisco.com > > > > > > Subject: [MMUSIC] Re: Multiple 'm' lines with the same port number > > > > > > Rajesh, > > > > > > > Is the use of multiple 'm=' lines with the same port number within > > > an > > > > SDP descriptor permitted? > > > > > > Presuming that the multiple m= lines are all RTP/AVP, then doing so > > > causes all of the payload formats listed on the m= lines to become > > > part of a single RTP session (unless they are distinguished by some > > > other aspect of addressing). Section 5.2 of the RTP spec addresses > > > NOT multiplexing different media in the same RTP session. > > > > > > > In SDP, as it is defined, all the media formats on an 'm=' line > are > > > of > > > > the same media type (e.g. audio, image, text etc.). > > > > > > > > Now consider the case in which two RTP media formats can use a > > > > destination port but are registered under different MIME types. > For > > > > example, text/t140 and audio/PCMU. In this case, there is no > > > recourse > > > > except to use multiple media lines with the same port number. For > > > example: > > > > > > The "can use a destination port" is the tricky part. We may not > > > agree. > > > > > > > m=audio 49232 RTP/AVP 0 > > > > m=text 49232 RTP/AVP 100 > > > > a=rtpmap:100 t140 > > > > > > > > My thought is that although this is unsual, it is not proscribed > by > > > > SDP syntax in RFC 2327 or in its latest internet draft. > > > > > > I believe this is proscribed by section 5.2 of the RTP spec because > > > these two media should not be multiplexed in one RTP session. > > > > > > My bet is that the real example you are thinking about is fax or > modem > > > over IP. We've been there before. > > > > > > -- Steve > > > > > > _______________________________________________ > > > mmusic mailing list > > > mmusic@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 16 18:32:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14545 for ; Tue, 16 Dec 2003 18:32:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOfe-00041L-0h for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 18:32:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNW5bH015449 for mmusic-archive@odin.ietf.org; Tue, 16 Dec 2003 18:32:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOfd-000416-TX for mmusic-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:32: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 SAA14503 for ; Tue, 16 Dec 2003 18:32:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOfa-0002D4-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOfZ-0002Cx-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:32:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWOfZ-0002Cu-00 for mmusic-web-archive@ietf.org; Tue, 16 Dec 2003 18:32:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOfY-00040a-Rt; Tue, 16 Dec 2003 18:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOfT-0003zy-8a for mmusic@optimus.ietf.org; Tue, 16 Dec 2003 18:31:55 -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 SAA14499 for ; Tue, 16 Dec 2003 18:31:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOfQ-0002CW-00 for mmusic@ietf.org; Tue, 16 Dec 2003 18:31:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOfO-0002CH-00 for mmusic@ietf.org; Tue, 16 Dec 2003 18:31:51 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AWOfN-0002Bs-00 for mmusic@ietf.org; Tue, 16 Dec 2003 18:31:49 -0500 Received: from csperkins-dsl.demon.co.uk ([80.176.225.173]:61788 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AWOeq-0004ot-00; Tue, 16 Dec 2003 23:31:16 +0000 Date: Tue, 16 Dec 2003 23:31:22 +0000 From: Colin Perkins To: Flemming Andreasen Cc: mmusic@ietf.org Subject: Multicast in... Re: [MMUSIC] Commetns on draft-ietf-mmusic-sdescriptions-02.txt Message-Id: <20031216233122.4ede9a5a.csp@csperkins.org> In-Reply-To: <3FDF785F.2E9640AB@cisco.com> References: <3FD9B7EB.6000500@ericsson.com> <3FDF785F.2E9640AB@cisco.com> Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8 (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.4 required=5.0 tests=AWL,RISK_FREE autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, [cc list trimmed, I assume everyone's on the mailing list...] --> Flemming Andreasen writes: ... > > 5. I think that one must look over the multicast cases and divide them > > into different use cases. I think that removing all the multicast is a > > bad choice as there are situation where it seems to work. I would start > > by dividing the usage into scenarios where one can use the a=crypto > > successfully. > > > > - The one to many, using ASM case. This is a advertisement case. Only > > the intended sender declares his SSRC/ROC/SEQ to ensure that all > > receivers does not use the senders SSRC and causes a two time pad with > > it. As all receivers are unsynchronized unless other mechanism is used, > > there might happen SSRC collisions. However if you either don't encrypt > > the RTCP, which is the only thing they will send, it is not a problem. > > Also if RTCP encryption is used, it might be deemed acceptable with the > > low risk of two time pads that exist. However this is clearly a > > security trade off. > > > > - The one to many, using SSM, as the receivers can't send to anybody > > else there is no problem. If one uses unicast RTCP feedback, the same > > security consideration regarding RTCP two time pads apply, however the > > distribution of the offending packets will not be the same as for ASM > > use cases. > > > > - The multicast conference case, with a central session control > > instance. As all participants speak only with the central control > > entity it can ensure that SSRC, collision is avoided if the same key > > are used. However in this case it is probably better to use individual > > master keys for each sender. However there seems to be some need to fix > > the a=crypto syntax to support this case. > > > > - The multicast conference, each sender announces there attributes > > individually to each participant. In this case all should be required > > to use individual master keys. Thus there is no risk for two time pads. > > > > As I see it with a few changes to the a=crypto attribute multicast can > > be fixed. However there is need to flesh out the scenarios and ensure > > that the signalling works for these. > > > > So as a conclusion there is need for more work in the multicast > > environment. Also statement as the second bullet in 4.1.1.2 is not > > correct. > > I agree that if we were to address multicast in this document, then we > would need to identify the different multicast cases and address them one > by one. The author team started doing that before publishing this > version, but did not find the task to be as simple as you suggest. We saw > several problems and complications related to multicast (e.g. the "use" > parameter, hierarchical/layered encoding schemes, SSRC "collissions" in > the SDP). We felt(and feel) fairly confident that inclusion of multicast > support in this document will result in a significant delay in > progressing this work, and since there is a real-life need to move this > along, we proposed to leave multicast for further study. There was > consensus in the meeting for that, and until now, there hasn't been any > objections on the mailing list either. I still favor leaving multicast > support for further study. I strongly agree with Flemming here: let's get the initial version of this draft published, then worry about multicast support. -- Colin Perkins http://csperkins.org/ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 01:40:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25036 for ; Thu, 18 Dec 2003 01:40:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWrpX-0000XB-NJ for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 01:40:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI6eFCB002050 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 01:40:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWrpX-0000Wz-G4 for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 01:40:15 -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 BAA25021 for ; Thu, 18 Dec 2003 01:40:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWrpU-0002tF-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 01:40:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWrpT-0002t7-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 01:40:11 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWrpT-0002t4-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 01:40:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWrpL-0000WG-KU; Thu, 18 Dec 2003 01:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWroe-0000VV-OP for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 01:39: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 BAA25010 for ; Thu, 18 Dec 2003 01:39:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWroW-0002sp-00 for mmusic@ietf.org; Thu, 18 Dec 2003 01:39:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWroV-0002si-00 for mmusic@ietf.org; Thu, 18 Dec 2003 01:39:12 -0500 Received: from huiluvaris.cs.tut.fi ([130.230.4.16] helo=mail2.cs.tut.fi ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AWroV-0002sf-00 for mmusic@ietf.org; Thu, 18 Dec 2003 01:39:11 -0500 Received: from samipelt (samipelt.atm.tut.fi [130.230.52.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.cs.tut.fi (Postfix) with ESMTP id EDABC4BC80; Thu, 18 Dec 2003 08:39:09 +0200 (EET) From: "Sami Peltotalo" To: "Mmusic" Date: Thu, 18 Dec 2003 08:39:57 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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 all, Does anyone want to transport multicast session announcements with another protocol than SAP? I have used FLUTE for this purpose. You can also test how it works with an open source implementation, see http://www.atm.tut.fi/mad. Cheers, Sami ps. (there is a short discussion below about this topic) > > Hi, > > I am currently working with topic, which handles service and > session announcements for multicast applications. SAP/SDP doesn't > suit very well for describing services, which could be > categorized to different groups, for example sports, news etc. So > that the receiver could build some kind of service hierarchy from > the announcements, and the user is able to browse the services > from categories he or she is interested. At least I have chosen > another protocols than SAP/SDP in my work. RMT working group's > FLUTE protocol seems to be very good choise for the transmission > of service descriptions, so I am using it. I can't use SAP > because it has limited payload size and payload can't be > segmented to different packets (my service and session > descriptions are much larger than for example one SDP > description). I am using XML in my service and session > descriptions so it was nice to notice that SDPng has now again > XML-Schema. Has anyone else considered to use FLUTE for > transmission of session announcements? > > Cheers, Sami > > > > > Does anyone have a problem with a new and better announcement > > protocol than SAP? > > > > We need a few things which SAP doesn't handle too well, which is > > one of the things covered by the Internet Media Guide effort in > > MMUSIC: > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt > > > > I guess anyone involved in applications/services over multicast > > could be interested, especially where point-to-point isn't desirable. > > > > I wanted to get an idea of any strong opinions before I stick out > > head and propose a real protocol task for MMUSIC next month. > > > > Cheers, Rod. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 02:35:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09400 for ; Thu, 18 Dec 2003 02:35:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWsge-0003ip-Ti for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 02:35:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI7Z8Ih014306 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 02:35:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWsge-0003if-Df for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 02:35:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09354 for ; Thu, 18 Dec 2003 02:35:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWsga-0004FE-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 02:35:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWsgZ-0004F7-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 02:35:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWsgZ-0004F4-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 02:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWsgY-0003hv-KC; Thu, 18 Dec 2003 02:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWsgP-0003hR-3B for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 02:34:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09342 for ; Thu, 18 Dec 2003 02:34:50 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWsgL-0004Ec-00 for mmusic@ietf.org; Thu, 18 Dec 2003 02:34:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWsgK-0004EV-00 for mmusic@ietf.org; Thu, 18 Dec 2003 02:34:48 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWsgJ-0004ES-00 for mmusic@ietf.org; Thu, 18 Dec 2003 02:34:48 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI7Yk604276 for ; Thu, 18 Dec 2003 09:34:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 09:34:42 +0200 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:34:43 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 09:34:42 +0200 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-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 18 Dec 2003 09:34:38 +0200 Message-ID: Thread-Topic: draft-ietf-mmusic-img-framework-01.txt Thread-Index: AcO5cgqYlsQf+JHkR56uFlNX1xPHRAAMvZZwAGUZQTAAin+JMA== To: Cc: , X-OriginalArrivalTime: 18 Dec 2003 07:34:42.0555 (UTC) FILETIME=[66D504B0:01C3C539] Content-Transfer-Encoding: 7bit Subject: [MMUSIC] IMG Reqs & FW v01 Internet-drafts: review please! 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello All The specifications on IMG requirements and framework are now in pretty good shape. These provide a solid basis on which to design a better-than-SAP announcement protocol, enable a diverse mix of description formats (SDP, MPEG7, etc), and personalise reception through filtering, subscription and request. There are a few open issues with what are the next steps so everyone's comments on these are very useful! The URLs to each document are: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-01.txt As discussed in Minneapolis (IETF Meeting 58) and before, we want to do a final public review before freezing these very soon so we would be delighted to get detailed review now (pre-working group last call). Private emails are welcome, though we'd like to encourage public review via the MMUSIC mailing list. We are looking forward to your ideas and comments. Thank you in advance! Best regards, Rod Walsh and all the IMG authors. IMG = Internet Media Guides = framework for media/Internet_content discovery and more... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 03:59:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11829 for ; Thu, 18 Dec 2003 03:59:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtzu-0007NF-HS for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 03:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI8x6v2028339 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 03:59:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtzu-0007N0-7s for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 03:59: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 DAA11817 for ; Thu, 18 Dec 2003 03:59:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtzr-0006SK-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 03:59:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtzp-0006Rx-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 03:59:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWtzp-0006Ru-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 03:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWtzp-0007MR-LJ; Thu, 18 Dec 2003 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 1AWtzB-0007LW-0F for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 03:58:21 -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 DAA11770 for ; Thu, 18 Dec 2003 03:58:19 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWtz8-0006Pr-00 for mmusic@ietf.org; Thu, 18 Dec 2003 03:58:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWtz6-0006Pd-00 for mmusic@ietf.org; Thu, 18 Dec 2003 03:58:18 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AWtz6-0006Pa-00 for mmusic@ietf.org; Thu, 18 Dec 2003 03:58:16 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI8wGI24350 for ; Thu, 18 Dec 2003 10:58:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 10:58:15 +0200 Received: from esebe022.NOE.Nokia.com ([172.21.138.113]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:58:15 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe022.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 10:58:14 +0200 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: Thu, 18 Dec 2003 10:58:14 +0200 Message-ID: Thread-Topic: IMG Reqs & FW IDs: next steps / actions Thread-Index: AcPAmDZg5XVaRcB4T7WUxCzcVo+CxgEqIWww To: Cc: , , , , , , , X-OriginalArrivalTime: 18 Dec 2003 08:58:14.0864 (UTC) FILETIME=[1266AD00:01C3C545] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] IMGs in MMUSIC & text on data models 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Colin (and All) I had a go at compressing the framework text on baseline data model = related to IMG so that it is clear that we're only leaving the hole and = not discussing the solution in MMUSIC. The result is below. Does this = satisfy your concerns? (Anyone else have comments?) Cheers, Rod. ---8<--- 6.3.4 Baseline (Meta)Data Model Specification =20 A minimal IMG data model may be useful to any implementer/deployment = of IMGs. The purpose would be to ensure that multiple metadata syntaxes (SDP, MPEG7, etc) can be related within the same body of IMG knowledge, regardless of any specific metadata and data models provided by the metadata syntaxes. Further work may be needed to meet application-specific requirements at defining metadata and data models for the successful deployment of IMGs in various environments. Existing (and future) work on these would need to be mapped to the IMG data types and use of the IMG Transfer Envelope concept as described above. This document is a framework for the delivery of IMG Metadata and thus further discussion on the definition data models for IMGs is beyond its scope. --->8--- FYI, the old version: ---8<--- 6.3.4 Baseline (Meta)Data Model Specification Relevant work-in-progress ensures that support of one, or very few, metadata syntaxes is not sufficient. Whereas the transport protocol should not restrict the metadata format, the IMG transfer envelope = may influence the choice metadata. However, metadata in binary format should not be prevented, in addition to the more abundant text and XML syntaxes currently available. =20 In most cases the actual content of metadata will be application, or service domain, specific. For instance, digital cinema distribution and television channels will have many different requirements. The task of specifying the bulk of the world's metadata is well beyond the scope of this document: a framework for the delivery of IMG metadata. We do anticipate that existing and future metadata specifications, including those of several working groups and standardization bodies, shall be able to use the services of the IMG framework. However, it is not essential to the current IMG work to specify standards with application-specific metadata. =20 It is essential that the three IMG data types are enabled, but it may not be necessary to achieve this for every metadata syntax available, nor may it be important to the IETF to cover every possibility for this. Generally, Complete IMG Descriptions will be correct for = existing syntaxes (e.g. for XML may be validated according to existing schema). The IMG Pointer data type may be served by a new syntax = (extremely minimal), or this syntax may be specified as part of = application-specific=20 metadata formats. Partial Descriptions may need new or modified syntaxes and semantics (e.g. XML schema) and mandatory fields for a Complete IMG Description may be redundant for a Partial Description. During and following the specification of the IMG transfer envelope, enabling the delivery of Partial Descriptions should be considered. =20 To gain implementation experience, it is essential to agree the = basics of IMG metadata for interoperability tests and subsequent=20 widespread deployments. So we anticipate that a minimal IMG data model would be useful to the Internet community. --->8--- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 04:01:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11916 for ; Thu, 18 Dec 2003 04:01:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWu1o-0007Vn-Vg for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:01:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI914ck028869 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:01:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWu1o-0007VW-Ls for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 04:01: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 EAA11900 for ; Thu, 18 Dec 2003 04:01:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWu1l-0006Uh-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:01:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWu1k-0006Ua-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:01:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWu1k-0006UX-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWu1m-0007TR-EL; Thu, 18 Dec 2003 04:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWu1J-0007Sn-3P for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 04:00: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 EAA11876 for ; Thu, 18 Dec 2003 04:00:31 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWu1G-0006UU-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:00:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWu1F-0006UN-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:00:30 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AWu1F-0006UK-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:00:29 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBI90T603154 for ; Thu, 18 Dec 2003 11:00:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 18 Dec 2003 11:00:28 +0200 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 11:00:29 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe023.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 18 Dec 2003 11:00:28 +0200 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: Thu, 18 Dec 2003 11:00:28 +0200 Message-ID: Thread-Topic: Test FLUTE for Service/Session Announcement for Multicast Apps Thread-Index: AcPFMaXC0oIJgpMbQ1eiT/sskNfTAQAE5jXQ To: , X-OriginalArrivalTime: 18 Dec 2003 09:00:28.0622 (UTC) FILETIME=[622086E0:01C3C545] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Sami Could you describe the main features of the announcement protocol you're = developing please? (and a comparison with SAP would be helpful) Cheers, Rod. > -----Original Message----- > From: ext Sami Peltotalo [mailto:sami.peltotalo@tut.fi] > Sent: Thursday, December 18, 2003 8:40 AM > To: Mmusic > Subject: Test FLUTE for Service/Session Announcement for=20 > Multicast Apps >=20 >=20 > Hi all, >=20 > Does anyone want to transport multicast session announcements=20 > with another > protocol than SAP? > I have used FLUTE for this purpose. You can also test how it=20 > works with an > open source implementation, > see http://www.atm.tut.fi/mad. >=20 > Cheers, Sami >=20 > ps. (there is a short discussion below about this topic) >=20 > > > > Hi, > > > > I am currently working with topic, which handles service and > > session announcements for multicast applications. SAP/SDP doesn't > > suit very well for describing services, which could be > > categorized to different groups, for example sports, news etc. So > > that the receiver could build some kind of service hierarchy from > > the announcements, and the user is able to browse the services > > from categories he or she is interested. At least I have chosen > > another protocols than SAP/SDP in my work. RMT working group's > > FLUTE protocol seems to be very good choise for the transmission > > of service descriptions, so I am using it. I can't use SAP > > because it has limited payload size and payload can't be > > segmented to different packets (my service and session > > descriptions are much larger than for example one SDP > > description). I am using XML in my service and session > > descriptions so it was nice to notice that SDPng has now again > > XML-Schema. Has anyone else considered to use FLUTE for > > transmission of session announcements? > > > > Cheers, Sami > > > > > > > > Does anyone have a problem with a new and better announcement > > > protocol than SAP? > > > > > > We need a few things which SAP doesn't handle too well, which is > > > one of the things covered by the Internet Media Guide effort in > > > MMUSIC: > > >=20 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt > > > > I guess anyone involved in applications/services over multicast > > could be interested, especially where point-to-point isn't = desirable. > > > > I wanted to get an idea of any strong opinions before I stick out > > head and propose a real protocol task for MMUSIC next month. > > > > Cheers, Rod. > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 04:19:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12283 for ; Thu, 18 Dec 2003 04:19:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWuJG-0008Ri-Mp for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:19:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI9J6Wx032464 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:19:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWuJF-0008RX-Gk for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 04:19: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 EAA12261 for ; Thu, 18 Dec 2003 04:19:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWuJC-0006r3-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWuJB-0006qw-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWuJB-0006qt-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWuJC-0008R1-Bo; Thu, 18 Dec 2003 04:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWuIT-0008Q4-5q for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 04:18:17 -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 EAA12244 for ; Thu, 18 Dec 2003 04:18:15 -0500 (EST) From: philippe.gentric@philips.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWuIQ-0006qT-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:18:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWuIP-0006qM-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:18:14 -0500 Received: from gw-nl6.philips.com ([212.153.235.103]) by ietf-mx with esmtp (Exim 4.12) id 1AWuIP-0006qJ-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:18:13 -0500 Received: from smtpscan-nl3.philips.com (smtpscan-nl3.philips.com [130.139.36.23]) by gw-nl6.philips.com (Postfix) with ESMTP id 579136B790; Thu, 18 Dec 2003 10:18:13 +0100 (MET) Received: from smtpscan-nl3.philips.com (localhost [127.0.0.1]) by localhost.philips.com (Postfix) with ESMTP id 6811019C4C; Thu, 18 Dec 2003 10:18:10 +0100 (MET) Received: from smtprelay-nl2.philips.com (smtprelay-eur2.philips.com [130.139.36.35]) by smtpscan-nl3.philips.com (Postfix) with ESMTP id 2EA8F19C48; Thu, 18 Dec 2003 10:18:09 +0100 (MET) Received: from hbg001soh.diamond.philips.com (e1soh01.diamond.philips.com [130.143.165.45]) by smtprelay-nl2.philips.com (8.9.3p3/8.8.5-1.2.2m-19990317) with ESMTP id KAA07444; Thu, 18 Dec 2003 10:18:08 +0100 (MET) Subject: Re: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps To: "Sami Peltotalo" Cc: "Mmusic" X-Mailer: Lotus Notes Release 5.0.9a January 7, 2002 Message-ID: Date: Thu, 18 Dec 2003 10:14:56 +0100 X-MIMETrack: Serialize by Router on hbg001soh/H/SERVER/PHILIPS(Release 5.0.11 |July 24, 2002) at 18/12/2003 10:19:53 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=NO_REAL_NAME autolearn=no version=2.60 Sami, first the URL: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt is stale, i think the correct one is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt Secondly could you explain if/why there is a specific need for a "joint" work between program guides and their mulitcast distribution ? Let me explain, my assumption is that one would either 1) browse the program guide using Web technologies (HTTP etc). and there is the specific work to define a standard format for such content 2) or receive the program guide as an equivalent bundle of files (i.e. the browser is used the same way but the files are local copies) and I agree in this last case an obvious choice is to use something like FLUTE for the delivery of the program guide file bundle ... but why is there a need for a connection between the 2 things i.e. the description format and the delivery protocol ? regards, Philippe Gentric Chief Architect Philips Software philippe.gentric@philips.com http://www.software.philips.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 04:43:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13181 for ; Thu, 18 Dec 2003 04:43:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWugZ-0000pN-GS for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:43:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI9hBMF003181 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 04:43:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWugZ-0000pE-1O for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 04:43:11 -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 EAA13158 for ; Thu, 18 Dec 2003 04:43:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWugV-0007aB-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:43:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWugU-0007a4-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:43:07 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWugU-0007a1-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 04:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWugP-0000oa-Fv; Thu, 18 Dec 2003 04:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWugB-0000oE-Am for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 04:42:47 -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 EAA13151 for ; Thu, 18 Dec 2003 04:42:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWug8-0007ZY-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:42:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWug7-0007ZP-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:42:43 -0500 Received: from huiluvaris.cs.tut.fi ([130.230.4.16] helo=mail2.cs.tut.fi ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AWug6-0007ZC-00 for mmusic@ietf.org; Thu, 18 Dec 2003 04:42:43 -0500 Received: from samipelt (samipelt.atm.tut.fi [130.230.52.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.cs.tut.fi (Postfix) with ESMTP id ACFD74BC80; Thu, 18 Dec 2003 11:42:42 +0200 (EET) From: "Sami Peltotalo" To: Cc: "Mmusic" Subject: RE: [MMUSIC] Test FLUTE for Service/Session Announcement for Multicast Apps Date: Thu, 18 Dec 2003 11:43:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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 Philippe, Yes the URL was old (old email). > Secondly could you explain if/why there is a specific need for a > "joint" work > between program guides and their mulitcast distribution ? I think there is no need for special "joint" work. It is just one use case. How many multicast distribution protocols are available currently? Is there need for better announcement protocol than SAP? > but why is there a need for a connection between the 2 things > i.e. the description format and the delivery protocol ? There is absolutely no need for this kind of connection. Delivery protocol may set some restrictions to the used description format. For example SAP can't deliver large XML or HTML media guides. Cheers, Sami > Sami, > > > first the URL: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-00.txt > is stale, i think the correct one is: > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt > > Secondly could you explain if/why there is a specific need for a > "joint" work > between program guides and their mulitcast distribution ? > > Let me explain, my assumption is that one would either > > 1) browse the program guide using Web technologies (HTTP etc). > and there is the specific work to define a standard format for > such content > > 2) or receive the program guide as an equivalent bundle of files > (i.e. the browser is used the same way but the files are local copies) > > and I agree in this last case an obvious choice is to use > something like FLUTE > for the delivery of the program guide file bundle ... > > but why is there a need for a connection between the 2 things > i.e. the description format and the delivery protocol ? > > regards, > > > Philippe Gentric > Chief Architect > Philips Software > philippe.gentric@philips.com > http://www.software.philips.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 08:34:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21195 for ; Thu, 18 Dec 2003 08:34:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyI1-0001pf-RF for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:34:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDY55n007037 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyI1-0001pQ-Me for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:34: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 IAA21178 for ; Thu, 18 Dec 2003 08:34:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyI0-00016t-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:34:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyHz-00016k-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:34:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyHz-00016h-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:34:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyHy-0001ok-8Q; Thu, 18 Dec 2003 08:34:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyHB-0001o1-8X for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 08:33:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21149 for ; Thu, 18 Dec 2003 08:33:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyH9-000153-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyH8-00014w-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:33:11 -0500 Received: from huiluvaris.cs.tut.fi ([130.230.4.16] helo=mail2.cs.tut.fi ident=postfix) by ietf-mx with esmtp (Exim 4.12) id 1AWyH8-00014s-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:33:10 -0500 Received: from samipelt (samipelt.atm.tut.fi [130.230.52.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.cs.tut.fi (Postfix) with ESMTP id 784EA4BC80; Thu, 18 Dec 2003 15:33:08 +0200 (EET) From: "Sami Peltotalo" To: Cc: Subject: RE: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps Date: Thu, 18 Dec 2003 15:33:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: 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 Rod, FLUTE suits well for transporting service announcements in unidirectional multicast environment. It can transport SDP files or any other file-based metadata, for example SMIL or other XML syntax. FLUTE has important functionalities to the transport: massive scalability, reliability/robustness, congestion control, segmentation of payload and independence of payload format. All of these features are poorly supported in the SAP protocol (Experimental RFC 2974). There is also other problems with SAP: the bandwidth limiting algorithm neither scales nor enables priority announcements; also SAP depends on Any Source Multicast (ASM) model so that in Source Specific Multicast (SSM) networks initial access to the announcement channel requires a different method. An important feature for service announcements is the channelisation of the announcements. This enables priorisation of the announcements. Several channels could be used (low priority, high priority etc.). Channelisation is an optinal feature that is supported in FLUTE. One issue is how to discover the initial announcement channel. SAP has a well known (IANA registered) group address, however this limits the scalability and inter-domain feasibility. With FLUTE it is possible to use for example hard-coded configuration or query from a web page. All the announcement can be provided on the initial announcement channel or metadata in this channel can describe other announcement channel(s) and the receiver can join to those and possibly leave the initial channel. Cheers, Sami > > Hi Sami > > Could you describe the main features of the announcement protocol > you're developing please? > > (and a comparison with SAP would be helpful) > > Cheers, Rod. > > > > > Hi all, > > > > Does anyone want to transport multicast session announcements > > with another > > protocol than SAP? > > I have used FLUTE for this purpose. You can also test how it > > works with an > > open source implementation, > > see http://www.atm.tut.fi/mad. > > > > Cheers, Sami > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 08:43:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21487 for ; Thu, 18 Dec 2003 08:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyQh-0002Qz-DA for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDh37V009351 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyQh-0002Qk-8z for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:43: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 IAA21474 for ; Thu, 18 Dec 2003 08:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyQf-0001Qh-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:43:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyQe-0001QU-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyQe-0001QR-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyQe-0002Oy-Uf; Thu, 18 Dec 2003 08:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyQd-0002On-Mh for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 08:42: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 IAA21458 for ; Thu, 18 Dec 2003 08:42:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyQc-0001Q8-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:42:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyQa-0001Pf-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:42:58 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AWyQa-0001Oj-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:42:56 -0500 Received: from gnvasmile.ebu.ch (unverified [10.73.222.210]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Thu, 18 Dec 2003 14:42:25 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 14:43:27 +0100 Message-ID: From: Evain Jean-Pierre To: "'mmusic@ietf.org'" Date: Thu, 18 Dec 2003 14:43:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] FW: IMG Reqs & FW v01 Internet-drafts: review please! 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,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I just joined the reflector to help having the following message going through more rapidly. Jean-Pierre -----Original Message----- From: Evain Jean-Pierre=20 Sent: jeudi, 18. d=E9cembre 2003 14:11 To: 'Rod.Walsh@nokia.com'; mmusic@ietf.org Cc: jo@tzi.uni-bremen.de; csp@csperkins.org; Evain Jean-Pierre Subject: RE: IMG Reqs & FW v01 Internet-drafts: review please! Dear Rod, Thank-you for sharing the information. I received your mail and read the documents with interest. As you know, I am particularly involved in TV-Anytime but also in DVB and was considering all this from a broadcaster perspective. I do not have time to go into the details right now but it seems that TV-Anytime and / or its members would like to comment. I am therefore going to forward this to the TV-Anytime community. There are two types of contributions that you can certainly expect: - technical contributions - generic contributions like e.g. on section 6.1 of the IMG framework where there is room for improvement of your vision of what TV-Anytime has done, is doing now, and its relationship to MPEG-7 (e.g. the TV-Anytime spec isn't based on MPEG-7 but shares a few schemas with MPEG-7 on user description metadata). These contributions can be envisaged in two ways: - contributions from individuals experts - contribution from TV-Anytime as a Forum What I need to know is the deadline. Until when do we have to make these comments? For your information, TV-Anytime is meeting during the second week of January in Geneva. I am also trying to organise a joint meeting with DVB IPI during this period. Can you wait until then? Woudl someone from MMUSIC be able to join? Please let me know... All the best for 2004! Best regards, Jean-Pierre Evain -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: jeudi, 18. d=E9cembre 2003 08:35 To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de; csp@csperkins.org Subject: IMG Reqs & FW v01 Internet-drafts: review please! Hello All The specifications on IMG requirements and framework are now in pretty good shape. These provide a solid basis on which to design a better-than-SAP announcement protocol, enable a diverse mix of description formats (SDP, MPEG7, etc), and personalise reception through filtering, subscription and request. There are a few open issues with what are the next steps so everyone's comments on these are very useful! The URLs to each document are: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-01.txt As discussed in Minneapolis (IETF Meeting 58) and before, we want to do a final public review before freezing these very soon so we would be delighted to get detailed review now (pre-working group last call). Private emails are welcome, though we'd like to encourage public review via the MMUSIC mailing list. We are looking forward to your ideas and comments. Thank you in advance! Best regards, Rod Walsh and all the IMG authors. IMG =3D Internet Media Guides =3D framework for media/Internet_content disc= overy and more... ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 08:49:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21734 for ; Thu, 18 Dec 2003 08:49: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 1AWyWU-0002b3-MW for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:49:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDn2Ux009975 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyWU-0002ao-Ix for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:49: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 IAA21731 for ; Thu, 18 Dec 2003 08:49:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyWT-0001h1-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:49:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyWS-0001gu-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:49:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyWS-0001gr-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyWS-0002aB-Ha; Thu, 18 Dec 2003 08:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyW1-0002ZF-KA for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 08:48: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 IAA21713 for ; Thu, 18 Dec 2003 08:48:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyW0-0001fN-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:48:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyVz-0001fF-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:48:31 -0500 Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx with esmtp (Exim 4.12) id 1AWyVy-0001ea-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:48:30 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id hBIDlp7S032475; Thu, 18 Dec 2003 14:47:51 +0100 Received: from sverresborg.uninett.no (localhost.localdomain [127.0.0.1]) by sverresborg.uninett.no (8.12.8/8.12.9) with ESMTP id hBIDlnkj027655; Thu, 18 Dec 2003 14:47:50 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id hBIDllIT027654; Thu, 18 Dec 2003 14:47:47 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Thu, 18 Dec 2003 14:47:47 +0100 From: Stig Venaas To: Sami Peltotalo Cc: mmusic@ietf.org, Rod.Walsh@nokia.com Subject: Re: [MMUSIC] RE: Test FLUTE for Service/Session Announcement for Multicast Apps Message-ID: <20031218134745.GE27441@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i 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 On Thu, Dec 18, 2003 at 03:33:59PM +0200, Sami Peltotalo wrote: [...] > There is also other problems with SAP: the bandwidth limiting algorithm > neither scales nor enables > priority announcements; also SAP depends on Any Source Multicast (ASM) model > so that in Source Specific > Multicast (SSM) networks initial access to the announcement channel requires > a different method. Also SAP won't work for IPv6, at least not globally, the way it's defined. There's no inter-domain solution, and having a single RP in the internet for the global SAP group won't work. [...] > One issue is how to discover the initial announcement channel. SAP has a > well known (IANA registered) > group address, however this limits the scalability and inter-domain > feasibility. With FLUTE it is possible > to use for example hard-coded configuration or query from a web page. > > All the announcement can be provided on the initial announcement channel or > metadata in this channel can > describe other announcement channel(s) and the receiver can join to those > and possibly leave the initial > channel. I'm not sure, but this might be at least one possible solution, Stig _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Thu Dec 18 08:51:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21873 for ; Thu, 18 Dec 2003 08:51:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyYU-0002kL-Hp for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:51:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIDp6R0010551 for mmusic-archive@odin.ietf.org; Thu, 18 Dec 2003 08:51:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyYU-0002k6-Dg for mmusic-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 08:51: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 IAA21836 for ; Thu, 18 Dec 2003 08:51:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWyYS-0001on-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:51:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWyYQ-0001oX-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:51:04 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWyYQ-0001oT-00 for mmusic-web-archive@ietf.org; Thu, 18 Dec 2003 08:51:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWyYR-0002i5-DA; Thu, 18 Dec 2003 08:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWxuw-0000wr-4x for mmusic@optimus.ietf.org; Thu, 18 Dec 2003 08:10:14 -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 IAA19829 for ; Thu, 18 Dec 2003 08:10:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWxuu-0006z1-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:10:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWxut-0006yu-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:10:12 -0500 Received: from mailgate3.ebu.ch ([194.158.3.52]) by ietf-mx with esmtp (Exim 4.12) id 1AWxus-0006tw-00 for mmusic@ietf.org; Thu, 18 Dec 2003 08:10:10 -0500 Received: from gnvasmile.ebu.ch (unverified) by MAILGATE3.EBU.CH (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Thu, 18 Dec 2003 14:08:15 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Dec 2003 14:10:40 +0100 Message-ID: From: Evain Jean-Pierre To: "'Rod.Walsh@nokia.com'" , mmusic@ietf.org Cc: jo@tzi.uni-bremen.de, csp@csperkins.org, Evain Jean-Pierre Date: Thu, 18 Dec 2003 14:10:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! 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,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Rod, Thank-you for sharing the information. I received your mail and read the documents with interest. As you know, I am particularly involved in TV-Anytime but also in DVB and was considering all this from a broadcaster perspective. I do not have time to go into the details right now but it seems that TV-Anytime and / or its members would like to comment. I am therefore going to forward this to the TV-Anytime community. There are two types of contributions that you can certainly expect: - technical contributions - generic contributions like e.g. on section 6.1 of the IMG framework where there is room for improvement of your vision of what TV-Anytime has done, is doing now, and its relationship to MPEG-7 (e.g. the TV-Anytime spec isn't based on MPEG-7 but shares a few schemas with MPEG-7 on user description metadata). These contributions can be envisaged in two ways: - contributions from individuals experts - contribution from TV-Anytime as a Forum What I need to know is the deadline. Until when do we have to make these comments? For your information, TV-Anytime is meeting during the second week of January in Geneva. I am also trying to organise a joint meeting with DVB IPI during this period. Can you wait until then? Woudl someone from MMUSIC be able to join? Please let me know... All the best for 2004! Best regards, Jean-Pierre Evain -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: jeudi, 18. d=E9cembre 2003 08:35 To: mmusic@ietf.org Cc: jo@tzi.uni-bremen.de; csp@csperkins.org Subject: IMG Reqs & FW v01 Internet-drafts: review please! Hello All The specifications on IMG requirements and framework are now in pretty good shape. These provide a solid basis on which to design a better-than-SAP announcement protocol, enable a diverse mix of description formats (SDP, MPEG7, etc), and personalise reception through filtering, subscription and request. There are a few open issues with what are the next steps so everyone's comments on these are very useful! The URLs to each document are: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-framework-01.txt As discussed in Minneapolis (IETF Meeting 58) and before, we want to do a final public review before freezing these very soon so we would be delighted to get detailed review now (pre-working group last call). Private emails are welcome, though we'd like to encourage public review via the MMUSIC mailing list. We are looking forward to your ideas and comments. Thank you in advance! Best regards, Rod Walsh and all the IMG authors. IMG =3D Internet Media Guides =3D framework for media/Internet_content disc= overy and more... ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 19 07:36:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06848 for ; Fri, 19 Dec 2003 07:36:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrI-0006dD-QK for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 07:35:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJCZuIW025485 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 07:35:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJrI-0006cy-L6 for mmusic-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 07:35:56 -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 HAA06832 for ; Fri, 19 Dec 2003 07:35:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJrC-0001JF-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:35:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJql-0001Ij-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:35:24 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXJql-0001IE-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:35:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJqQ-0006Xq-N3; Fri, 19 Dec 2003 07:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXJpN-0006Wt-Je for mmusic@optimus.ietf.org; Fri, 19 Dec 2003 07:34:17 -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 HAA06805 for ; Fri, 19 Dec 2003 07:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXJpC-0001HB-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:33:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXJom-0001Go-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:33:21 -0500 Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1AXJom-0001Fb-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:33:20 -0500 Received: from mangole ([130.209.247.112]:1136 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1AXJng-0000Ko-00; Fri, 19 Dec 2003 12:32:12 +0000 Date: Fri, 19 Dec 2003 12:32:22 +0000 From: Colin Perkins To: Cc: Hitoshi.Asaeda@sophia.inria.fr, hgs@cs.columbia.edu, toni.paila@nokia.com, jo@tzi.uni-bremen.de, dku@tzi.org, nom@flab.fujitsu.co.jp, juha-pekka.luoma@nokia.com, mmusic@ietf.org Message-Id: <20031219123222.55c404d5.csp@csperkins.org> In-Reply-To: References: Organization: http://csperkins.org/ X-Mailer: Sylpheed version 0.9.8a (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 Subject: [MMUSIC] Re: IMGs in MMUSIC & text on data models 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 Rod, --> writes: > I had a go at compressing the framework text on baseline data model > related to IMG so that it is clear that we're only leaving the hole and > not discussing the solution in MMUSIC. The result is below. Does this > satisfy your concerns? Yes, is okay. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 19 07:53:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07308 for ; Fri, 19 Dec 2003 07:53:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXK7w-0007KS-33 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 07:53:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJCr8V4028166 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 07:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXK7v-0007KD-Vm for mmusic-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 07:53:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07295 for ; Fri, 19 Dec 2003 07:53:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXK7v-0001qK-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:53:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXK7t-0001qD-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:53:06 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXK7t-0001qA-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 07:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXK7p-0007GW-9n; Fri, 19 Dec 2003 07:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXK7k-0007GF-B3 for mmusic@optimus.ietf.org; Fri, 19 Dec 2003 07:52:56 -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 HAA07292 for ; Fri, 19 Dec 2003 07:52:54 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXK7j-0001q5-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:52:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXK7f-0001pn-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:52:53 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AXK7f-0001pb-00 for mmusic@ietf.org; Fri, 19 Dec 2003 07:52:51 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJCqo014462 for ; Fri, 19 Dec 2003 14:52:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 14:52:42 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 14:52:41 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 14:52:41 +0200 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: Fri, 19 Dec 2003 14:52:40 +0200 Message-ID: Thread-Topic: IMG Reqs & FW v01 Internet-drafts: review please! Thread-Index: AcPFaEg48zJXRguKTH6qlLTE5KjfFQAuw2tA To: Cc: , , , X-OriginalArrivalTime: 19 Dec 2003 12:52:41.0202 (UTC) FILETIME=[FD014520:01C3C62E] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! 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,EXCUSE_16,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre All contributions and reviews are welcome, and everything constructive = (with an idea of how to make progress) is great regarless whetehr the = critisism is positive or negative. The best way to contribute is in small bursts as several small ideas can = be dealt with progressively and a single large batch of feedabck is = bound to introduce some latency and risk missing some of the quieter = points. Individual and organizational are fine, but it is important that = the people emailing the comments are prepared to partcipate in the = discussion (i.e. understand the issues or in close proximity to the = experts who do) - this is also a good reason for reviews in short bursts = as you can spread the "competence burden". The dead line is "as soon as possible". I personally hope we will last = call (solicit final reviews) very soon and close this before the end of = January. If there are convincing arguments that additional valuable = input will not arrive until February we can talk about a second last = call if the points were not addressed in the first. (i.e. the dead-line = is mid/end-January, but serious requests for time to add details to = comments will probably be treat with enthusiasm and accomodation). = (Note, a last call is initiated where the authors and chairs feel the = documents are ready, however a decision to ask the IESG to consider for = RFC publication often follows more than one last call). The MMUSIC chairs orchestrate this process so: Colin & Joerg, did that = sound about right? Joerg has talked with IPI, as well as Toni Paila (one of my collegaues) = (at this point I have no idea whether I would be available for MMUSIC = input into an TVA+IPI meeting - depends on timing and location). Let's = follow up on this. Cheers and MERRY CHRISTMAS!!! Rod. > -----Original Message----- > From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] > Sent: Thursday, December 18, 2003 3:11 PM > To: Walsh Rod (NRC/Tampere); mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de; csp@csperkins.org; Evain Jean-Pierre > Subject: RE: IMG Reqs & FW v01 Internet-drafts: review please! >=20 >=20 > Dear Rod, >=20 > Thank-you for sharing the information. >=20 > I received your mail and read the documents with interest. >=20 > As you know, I am particularly involved in TV-Anytime but=20 > also in DVB and > was considering all this from a broadcaster perspective. >=20 > I do not have time to go into the details right now but it seems that > TV-Anytime and / or its members would like to comment. I am=20 > therefore going > to forward this to the TV-Anytime community. >=20 > There are two types of contributions that you can certainly expect: >=20 > - technical contributions > - generic contributions like e.g. on section 6.1 of the IMG=20 > framework where > there is room for improvement of your vision of what=20 > TV-Anytime has done, is > doing now, and its relationship to MPEG-7 (e.g. the=20 > TV-Anytime spec isn't > based on MPEG-7 but shares a few schemas with MPEG-7 on user=20 > description > metadata). >=20 > These contributions can be envisaged in two ways: >=20 > - contributions from individuals experts > - contribution from TV-Anytime as a Forum >=20 > What I need to know is the deadline. Until when do we have=20 > to make these > comments? For your information, TV-Anytime is meeting during=20 > the second > week of January in Geneva. I am also trying to organise a=20 > joint meeting > with DVB IPI during this period. >=20 > Can you wait until then? >=20 > Woudl someone from MMUSIC be able to join? >=20 > Please let me know... >=20 > All the best for 2004! >=20 > Best regards, >=20 > Jean-Pierre Evain >=20 > -----Original Message----- > From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 > Sent: jeudi, 18. d=E9cembre 2003 08:35 > To: mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de; csp@csperkins.org > Subject: IMG Reqs & FW v01 Internet-drafts: review please! >=20 >=20 > Hello All >=20 > The specifications on IMG requirements and framework are now=20 > in pretty good > shape. >=20 > These provide a solid basis on which to design a better-than-SAP > announcement protocol, enable a diverse mix of description=20 > formats (SDP, > MPEG7, etc), and personalise reception through filtering,=20 > subscription and > request. >=20 > There are a few open issues with what are the next steps so everyone's > comments on these are very useful! The URLs to each document are: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-fram ework-01.txt As discussed in Minneapolis (IETF Meeting 58) and before, we want to do = a final public review before freezing these very soon so we would be = delighted to get detailed review now (pre-working group last call). Private emails = are welcome, though we'd like to encourage public review via the MMUSIC = mailing list. We are looking forward to your ideas and comments. Thank you in advance! Best regards, Rod Walsh and all the IMG authors. IMG =3D Internet Media Guides =3D framework for media/Internet_content = discovery and more... ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 19 09:12:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09766 for ; Fri, 19 Dec 2003 09:12:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLML-0001oc-EH for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:12:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEC5wC006972 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:12:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLML-0001oN-5d for mmusic-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:12: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 JAA09727 for ; Fri, 19 Dec 2003 09:12:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLMJ-0004CK-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:12:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLMH-0004CD-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:12:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLMH-0004CA-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:12:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLMI-0001nP-1o; Fri, 19 Dec 2003 09:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLM8-0001n2-BO for mmusic@optimus.ietf.org; Fri, 19 Dec 2003 09:11:52 -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 JAA09720 for ; Fri, 19 Dec 2003 09:11:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLM6-0004Al-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLM5-0004Ae-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:11:50 -0500 Received: from mailgate3.ebu.ch ([194.158.3.52]) by ietf-mx with esmtp (Exim 4.12) id 1AXLM4-00045q-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:11:48 -0500 Received: from gnvasmile.ebu.ch (unverified) by MAILGATE3.EBU.CH (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 19 Dec 2003 15:09:52 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 15:12:17 +0100 Message-ID: From: Evain Jean-Pierre To: "'Rod.Walsh@nokia.com'" Cc: mmusic@ietf.org, jo@tzi.uni-bremen.de, csp@csperkins.org, toni.paila@nokia.com Date: Fri, 19 Dec 2003 15:12:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Rod, Time is probably pressing but I think there is a need to consider all these issues carefully all the more so as many parties are interested in not destabilising the effort spent in DVB and in TV-Anytime. DVB has adopted TV-Anytime that is now an ETSI standard. TV-Anytime is a cornerstone of many DVB developments including most recently in DVB IPTV. Reasonable effort was spent through cross-membership harmonising between TVA and DVB IPI and more discussion is foreseen on metadata. This is without saying that we keep on eye on DVB UMTS that Nokia is necessarily aware of. We are interested in ensuring that MMUSIC does a good job and we shall certainly collaborate in a positive spirit. As I mentioned, we shall come back to you with comments in diverse form, from individuals and most likely from the TVA Forum itself. Whether the bursts will be small or large remains to be decided by those who will contribute. It seems that mid-January is okay and we shall be ready on time. I would encourage you to turn up at the TV-Anytime January (13-16) meeting in Geneva, which is a lucky location when considering who might potentially be involved and the deadlines. DVB IPI is meeting in Geneva on 13-14 January. It would therefore seem that a joint meeting could take place on the 13 in the afternoon on on the 14th. I am currently trying to get an answer from DVB IPI, whose Chairman is directly involved in TV-Anytime. Short joint meetings are certainly more productive than long e-mails. Best regards, Jean-Pierre -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: vendredi, 19. d=E9cembre 2003 13:53 To: Evain Jean-Pierre Cc: mmusic@ietf.org; jo@tzi.uni-bremen.de; csp@csperkins.org; toni.paila@nokia.com Subject: RE: IMG Reqs & FW v01 Internet-drafts: review please! Hi Jean-Pierre All contributions and reviews are welcome, and everything constructive (with an idea of how to make progress) is great regarless whetehr the critisism is positive or negative. The best way to contribute is in small bursts as several small ideas can be dealt with progressively and a single large batch of feedabck is bound to introduce some latency and risk missing some of the quieter points. Individual and organizational are fine, but it is important that the people emailing the comments are prepared to partcipate in the discussion (i.e. understand the issues or in close proximity to the experts who do) - this is also a good reason for reviews in short bursts as you can spread the "competence burden". The dead line is "as soon as possible". I personally hope we will last call (solicit final reviews) very soon and close this before the end of January. If there are convincing arguments that additional valuable input will not arrive until February we can talk about a second last call if the points were not addressed in the first. (i.e. the dead-line is mid/end-January, but serious requests for time to add details to comments will probably be treat with enthusiasm and accomodation). (Note, a last call is initiated where the authors and chairs feel the documents are ready, however a decision to ask the IESG to consider for RFC publication often follows more than one last call). The MMUSIC chairs orchestrate this process so: Colin & Joerg, did that sound about right? Joerg has talked with IPI, as well as Toni Paila (one of my collegaues) (at this point I have no idea whether I would be available for MMUSIC input into an TVA+IPI meeting - depends on timing and location). Let's follow up on this. Cheers and MERRY CHRISTMAS!!! Rod. > -----Original Message----- > From: ext Evain Jean-Pierre [mailto:evain@ebu.ch] > Sent: Thursday, December 18, 2003 3:11 PM > To: Walsh Rod (NRC/Tampere); mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de; csp@csperkins.org; Evain Jean-Pierre > Subject: RE: IMG Reqs & FW v01 Internet-drafts: review please! >=20 >=20 > Dear Rod, >=20 > Thank-you for sharing the information. >=20 > I received your mail and read the documents with interest. >=20 > As you know, I am particularly involved in TV-Anytime but > also in DVB and > was considering all this from a broadcaster perspective. >=20 > I do not have time to go into the details right now but it seems that=20 > TV-Anytime and / or its members would like to comment. I am therefore=20 > going to forward this to the TV-Anytime community. >=20 > There are two types of contributions that you can certainly expect: >=20 > - technical contributions > - generic contributions like e.g. on section 6.1 of the IMG > framework where > there is room for improvement of your vision of what=20 > TV-Anytime has done, is > doing now, and its relationship to MPEG-7 (e.g. the=20 > TV-Anytime spec isn't > based on MPEG-7 but shares a few schemas with MPEG-7 on user=20 > description > metadata). >=20 > These contributions can be envisaged in two ways: >=20 > - contributions from individuals experts > - contribution from TV-Anytime as a Forum >=20 > What I need to know is the deadline. Until when do we have > to make these > comments? For your information, TV-Anytime is meeting during=20 > the second > week of January in Geneva. I am also trying to organise a=20 > joint meeting > with DVB IPI during this period. >=20 > Can you wait until then? >=20 > Woudl someone from MMUSIC be able to join? >=20 > Please let me know... >=20 > All the best for 2004! >=20 > Best regards, >=20 > Jean-Pierre Evain >=20 > -----Original Message----- > From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com] > Sent: jeudi, 18. d=E9cembre 2003 08:35 > To: mmusic@ietf.org > Cc: jo@tzi.uni-bremen.de; csp@csperkins.org > Subject: IMG Reqs & FW v01 Internet-drafts: review please! >=20 >=20 > Hello All >=20 > The specifications on IMG requirements and framework are now > in pretty good > shape. >=20 > These provide a solid basis on which to design a better-than-SAP=20 > announcement protocol, enable a diverse mix of description formats=20 > (SDP, MPEG7, etc), and personalise reception through filtering, > subscription and > request. >=20 > There are a few open issues with what are the next steps so everyone's=20 > comments on these are very useful! The URLs to each document are: >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-req-01.txt > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-img-fram ework-01.txt As discussed in Minneapolis (IETF Meeting 58) and before, we want to do a final public review before freezing these very soon so we would be delighted to get detailed review now (pre-working group last call). Private emails are welcome, though we'd like to encourage public review via the MMUSIC mailing list. We are looking forward to your ideas and comments. Thank you in advance! Best regards, Rod Walsh and all the IMG authors. IMG =3D Internet Media Guides =3D framework for media/Internet_content disc= overy and more... ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** =20 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 19 09:37:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10351 for ; Fri, 19 Dec 2003 09:37:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLkM-0002jG-JG for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:36:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEasUe010484 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLkM-0002j1-Fq for mmusic-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:36:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10329 for ; Fri, 19 Dec 2003 09:36:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLkF-0004oE-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:36:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLjo-0004ns-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:36:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXLjo-0004nC-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:36:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLjV-0002eq-C5; Fri, 19 Dec 2003 09:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXLiu-0002dK-Dm for mmusic@optimus.ietf.org; Fri, 19 Dec 2003 09:35:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10283 for ; Fri, 19 Dec 2003 09:35:15 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXLig-0004lT-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:35:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXLiG-0004l3-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:34:45 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AXLiG-0004kl-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:34:44 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hBJEYXU14899 for ; Fri, 19 Dec 2003 16:34:33 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 19 Dec 2003 16:34:33 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:34:30 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 19 Dec 2003 16:34:30 +0200 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: Fri, 19 Dec 2003 16:34:29 +0200 Message-ID: Thread-Topic: IMG Reqs & FW v01 Internet-drafts: review please! Thread-Index: AcPGOfpE2tzrTPv9SYuWJILjI9mz/wAAOgSQ To: Cc: , , , X-OriginalArrivalTime: 19 Dec 2003 14:34:30.0639 (UTC) FILETIME=[36835FF0:01C3C63D] Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Jean-Pierre et al. > It seems that mid-January is okay and we shall be ready on time. Excellent, thank you for your effort on this. > I would encourage you to turn up at the TV-Anytime January=20 > (13-16) meeting > in Geneva, which is a lucky location when considering who=20 I'll try to negotiate it with my boss :) > Time is probably pressing but I think there is a need to=20 > consider all these > issues carefully all the more so as many parties are interested in not > destabilising the effort spent in DVB and in TV-Anytime. Certainly. I've been following these issues from a distance and it seems = that TVA metadata fit into IMGs is smooth and trouble free - technically = and politically. I'd be very happy to hear the opinions of others too. As I see it the fit is (please correct/educate me where I miss = something): * TVA metadata could be transported over DVB-GBS/SI and over = DVB-IP/SD&S. If SD&S were possible over IMG delivery protocols then = already TVA over IMG fits the work already done (note, the SD&S = announcement protocol for DVB2/IPI_Phase2 is totally open at this time). * TVA metadata does not conflict with any ideas in IMG (nor does it's = data model). In fact, since TVA explicitly says that it will not = standardise an announcement protocol and MMUSIC/IMGs explicitly states = that it will not standardise application-specific metadata and data = models then the situation seems harmonious to me. * The items for review (requirements and framework) do not define = delivery protocols, but do explain the need. * The cross-organisation efforts of TVA are delivery (protocol) related = an thus would be very good input to the delivery protocol work = undertaken in MMUSIC following any decision to charter this. (i.e. = delivery portocol commons are not urgent and only possible on the = individual Internet-draft submissions which are not subject to this last = call). > We are interested in ensuring that MMUSIC does a good job and we shall > certainly collaborate in a positive spirit. We are very grateful to hear expert opinion from a variety of fields. = Likewise, if you have any questions on how IMG can be leveraged for TVA = objectives, we'll do our best to help you out. Best Christmas regards, Rod Walsh. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Fri Dec 19 09:54:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10869 for ; Fri, 19 Dec 2003 09:54: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 1AXM0y-0003pq-88 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:54:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJEs4oN014741 for mmusic-archive@odin.ietf.org; Fri, 19 Dec 2003 09:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXM0y-0003pg-52 for mmusic-web-archive@optimus.ietf.org; Fri, 19 Dec 2003 09:54: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 JAA10866 for ; Fri, 19 Dec 2003 09:54:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXM0w-0005N5-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:54:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXM0u-0005My-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:54:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AXM0u-0005Mv-00 for mmusic-web-archive@ietf.org; Fri, 19 Dec 2003 09:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXM0u-0003p1-Lf; Fri, 19 Dec 2003 09:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AXM0M-0003og-RD for mmusic@optimus.ietf.org; Fri, 19 Dec 2003 09:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10853 for ; Fri, 19 Dec 2003 09:53:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AXM0K-0005MF-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AXM0J-0005M8-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:53:24 -0500 Received: from mailgate2.ebu.ch ([194.158.3.44]) by ietf-mx with esmtp (Exim 4.12) id 1AXM0J-0005Lz-00 for mmusic@ietf.org; Fri, 19 Dec 2003 09:53:23 -0500 Received: from gnvasmile.ebu.ch (unverified [10.73.222.210]) by mailgate2.ebu.ch (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Fri, 19 Dec 2003 15:52:51 +0100 Received: by gnvasmile.ebu.ch with Internet Mail Service (5.5.2653.19) id ; Fri, 19 Dec 2003 15:53:51 +0100 Message-ID: From: Evain Jean-Pierre To: "'Rod.Walsh@nokia.com'" Cc: mmusic@ietf.org, jo@tzi.uni-bremen.de, csp@csperkins.org, toni.paila@nokia.com Date: Fri, 19 Dec 2003 15:53:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [MMUSIC] RE: IMG Reqs & FW v01 Internet-drafts: review please! 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.2 required=5.0 tests=AWL,EXCUSE_16 autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Rod, Having read the MMUSIC documentation, I do not see any particular difficulty but I prefer relying on true experts from TVA to check that this the case because we have a part of our specification dealing with metadata service discovery over IP and here we have been looking at what DVB IPI was doing too. All the best for 2004! Jean-Pierre -----Original Message----- From: Rod.Walsh@nokia.com [mailto:Rod.Walsh@nokia.com]=20 Sent: vendredi, 19. d=E9cembre 2003 15:34 To: Evain Jean-Pierre Cc: mmusic@ietf.org; jo@tzi.uni-bremen.de; csp@csperkins.org; toni.paila@nokia.com Subject: RE: IMG Reqs & FW v01 Internet-drafts: review please! Hi Jean-Pierre et al. > It seems that mid-January is okay and we shall be ready on time. Excellent, thank you for your effort on this. > I would encourage you to turn up at the TV-Anytime January > (13-16) meeting > in Geneva, which is a lucky location when considering who=20 I'll try to negotiate it with my boss :) > Time is probably pressing but I think there is a need to > consider all these > issues carefully all the more so as many parties are interested in not > destabilising the effort spent in DVB and in TV-Anytime. Certainly. I've been following these issues from a distance and it seems that TVA metadata fit into IMGs is smooth and trouble free - technically and politically. I'd be very happy to hear the opinions of others too. As I see it the fit is (please correct/educate me where I miss something): * TVA metadata could be transported over DVB-GBS/SI and over DVB-IP/SD&S. If SD&S were possible over IMG delivery protocols then already TVA over IMG fits the work already done (note, the SD&S announcement protocol for DVB2/IPI_Phase2 is totally open at this time). * TVA metadata does not conflict with any ideas in IMG (nor does it's data model). In fact, since TVA explicitly says that it will not standardise an announcement protocol and MMUSIC/IMGs explicitly states that it will not standardise application-specific metadata and data models then the situation seems harmonious to me. * The items for review (requirements and framework) do not define delivery protocols, but do explain the need. * The cross-organisation efforts of TVA are delivery (protocol) related an thus would be very good input to the delivery protocol work undertaken in MMUSIC following any decision to charter this. (i.e. delivery portocol commons are not urgent and only possible on the individual Internet-draft submissions which are not subject to this last call). > We are interested in ensuring that MMUSIC does a good job and we shall=20 > certainly collaborate in a positive spirit. We are very grateful to hear expert opinion from a variety of fields. Likewise, if you have any questions on how IMG can be leveraged for TVA objectives, we'll do our best to help you out. Best Christmas regards, Rod Walsh. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** =20 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Tue Dec 23 15:38:18 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08546 for ; Tue, 23 Dec 2003 15:38:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtHq-0008M8-Nb for mmusic-archive@odin.ietf.org; Tue, 23 Dec 2003 15:37:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKboAd032114 for mmusic-archive@odin.ietf.org; Tue, 23 Dec 2003 15:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtHq-0008Lk-Aw for mmusic-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:37:50 -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 PAA08472 for ; Tue, 23 Dec 2003 15:37:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtHo-0001yA-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:37:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtG5-0001u3-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtFB-0001pd-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtF8-0007W8-W7; Tue, 23 Dec 2003 15:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtF5-0007VU-BD for mmusic@optimus.ietf.org; Tue, 23 Dec 2003 15:34:59 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07940; Tue, 23 Dec 2003 15:34:56 -0500 (EST) Message-Id: <200312232034.PAA07940@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Dec 2003 15:34:56 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-req-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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=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 Filename : draft-ietf-mmusic-img-req-02.txt Pages : 21 Date : 2003-12-23 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-req-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-req-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-23153128.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-req-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153128.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 Dec 23 15:38:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08566 for ; Tue, 23 Dec 2003 15:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtHu-0008Mj-7j for mmusic-archive@odin.ietf.org; Tue, 23 Dec 2003 15:37:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBNKbsTN032151 for mmusic-archive@odin.ietf.org; Tue, 23 Dec 2003 15:37:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtHp-0008LG-AQ for mmusic-web-archive@optimus.ietf.org; Tue, 23 Dec 2003 15:37:50 -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 PAA08467 for ; Tue, 23 Dec 2003 15:37:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYtHn-0001y5-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:37:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYtG4-0001tv-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:36:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYtFB-0001pc-00 for mmusic-web-archive@ietf.org; Tue, 23 Dec 2003 15:35:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtF8-0007Vy-Js; Tue, 23 Dec 2003 15:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYtF0-0007Uf-GZ for mmusic@optimus.ietf.org; Tue, 23 Dec 2003 15:34:54 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07926; Tue, 23 Dec 2003 15:34:51 -0500 (EST) Message-Id: <200312232034.PAA07926@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 23 Dec 2003 15:34:51 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-img-framework-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Multiparty Multimedia Session Control Working Group List-Post: List-Help: List-Subscribe: , 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,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) : Y. Nomura Filename : draft-ietf-mmusic-img-framework-02.txt Pages : 23 Date : 2003-12-23 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 several use case scenarios requirering the IMG framework, 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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-img-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-img-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-12-23153119.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-img-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-img-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-12-23153119.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From exim@www1.ietf.org Mon Dec 29 21:26:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24283 for ; Mon, 29 Dec 2003 21:26:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab9aM-0002Sm-GY for mmusic-archive@odin.ietf.org; Mon, 29 Dec 2003 21:26:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBU2QIMt009462 for mmusic-archive@odin.ietf.org; Mon, 29 Dec 2003 21:26:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab9aM-0002SX-DI for mmusic-web-archive@optimus.ietf.org; Mon, 29 Dec 2003 21:26:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24276 for ; Mon, 29 Dec 2003 21:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab9aJ-0003JI-00 for mmusic-web-archive@ietf.org; Mon, 29 Dec 2003 21:26:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab9YX-0003G7-00 for mmusic-web-archive@ietf.org; Mon, 29 Dec 2003 21:24:26 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Ab9XD-0003BV-00 for mmusic-web-archive@ietf.org; Mon, 29 Dec 2003 21:23:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab9XB-0002MW-Fl; Mon, 29 Dec 2003 21:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ab9WV-0002L0-Uv for mmusic@optimus.ietf.org; Mon, 29 Dec 2003 21:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24125 for ; Mon, 29 Dec 2003 21:22:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ab9WT-00039n-00 for mmusic@ietf.org; Mon, 29 Dec 2003 21:22:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ab9Ud-000360-00 for mmusic@ietf.org; Mon, 29 Dec 2003 21:20:24 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1Ab9TB-00031X-00 for mmusic@ietf.org; Mon, 29 Dec 2003 21:18:53 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 30 Dec 2003 02:19:03 +0000 Received: from cisco.com (sjc-vpn3-734.cisco.com [10.21.66.222]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hBU2ILQu002707; Mon, 29 Dec 2003 18:18:21 -0800 (PST) Message-ID: <3FF0E06C.74E3A66F@cisco.com> Date: Mon, 29 Dec 2003 21:18:20 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "mmusic@ietf.org" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SSRCs in sdescriptions - the problem and proposed resolution 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,TO_ADDRESS_EQ_REAL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The SDP security descriptions to setup SRTP media stream (draft-ietf-mmusic-sdescriptions) defines the SRC parameter which contains the following three fields: - SSRC: The SSRC for a crypto context being described. - ROC: The roll-over counter for the SSRC - SEQ: The RTP sequence number for the SSRC The SSRC part of this parameter is motivated by two things: 1. Identify the crypto context for which the ROC and SEQ are provided. 2. Prevent SSRC collissions. Point number two is the problematic one. The reason we want to prevent SSRC collissions is so we can share a master key without running into the two-time pad issue. Preventing SSRC collissions through signaling is however not without problems. In the offer/answer model, the offerer can include a list of SSRC values, which the answerer can reject in case of a collission. However, if the answerer includes a list of SSRC values, the offerer cannot reject those values. Outside of offer/answer, it's even less clear how this would work. Possibe solutions include: 1. Get rid of the problem in the first place, i.e. allow for SSRC collissions. This can be done securely by requiring that the master key cannot be shared in the send and receive direction. It can be done somewhat insecurely by accepting the two-time pad problem as a potential weakness when shared master key(s) are used. The risk of this happenening is about 2^(-48). 2. Require that SSRC collissions are prevented by means outside the scope of the protocol. Possible ways of doing this include: - Central SSRC allocation and distribution of unique SSRCs to the session participants. This is not a very general solution. - Forgo the basic property of having negotiation complete in a single roundtrip, i.e. effectively allow the offerer to accept or deny SSRCs selected by the answerer. Security preconditions for example can be used to achieve this. However, this only addresses the problem in the context of offer/answer and furthermore leads to lengthier negotiation. 3. In the offer/answer model, have the offerer determine the SSRC values to be used by both the offerer and answerer. If the answerer does not find these acceptable, he can always reject the offer (and preferably include a list of acceptable SSRC values). Apart from the more philosophical issues of having one party control the SSRCs used by another party, there is an issue of what the answerer does in case the offerer did not suggest any SSRCs. As with option 2, this also only addresses the problem in the context of offer/answer and furthermore can lead to lengthier negotiation. The suggestion here is to go with a combination of option 1 and 2: Master key(s) MUST NOT be shared in the send and receive direction unless the two parties can guarantee SSRC uniqueness by means outside the scope of the SDP security descriptions. Please speak up if you disagree with this and/or if you can think of a better suggestion. Thanks Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic