From mmusic-admin@ietf.org Mon Apr 1 04:33:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08498 for ; Mon, 1 Apr 2002 04:33:16 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21161; Mon, 1 Apr 2002 04:27:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA21130 for ; Mon, 1 Apr 2002 04:27:27 -0500 (EST) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07930 for ; Mon, 1 Apr 2002 04:27:24 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g319QoKR014659 for ; Mon, 1 Apr 2002 01:26:50 -0800 Received: from mmmm (12-231-29-208.client.attbi.com [12.231.29.208]) by real.com (8.12.2/8.12.2) with ESMTP id g319Qol2010131 for ; Mon, 1 Apr 2002 01:26:50 -0800 Date: Mon, 1 Apr 2002 01:21:46 -0800 (PST) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: Telecon agenda for April 3 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, Another Wednesday telecon is coming up this week. Agenda might look familiar...it's much of what we hoped to cover in Minneapolis at the lunch session, with a focus on items immediately relevant to getting RTSP to Draft Standard. This agenda will be on http://rtsp.org/telecon sometime tomorrow. In the meantime, it's included below. Please RSVP by 12pm Tuesday PST. Thanks Rob * Close on other decisions in Wednesday RTSP discussion (15 minutes) * Clarify aggregate/non-aggregate control * Reworked state machine 1. In the both playing states, is SETUP and TEARDOWN allowed? 2. When a media reaches the end of a media should the resume point be set to begining of clip, although it will remain in playing state? 3. When a media reaches the end of the specified range(s) should the resume point be set to 0.0 or the end of the range? 4. Should we have the READY-nm state that this version shows? 5. When doing setup for recording is there a requirement to have done announce before? 6. Should REDIRECT without range or reaching the readirect point result in imediatly closeing of the session? This is suggested by the old client state machine that send the client to Init on redirect. The text in chapter 10.10 says that the client should issue a teardown of previous session. * Should we eliminate queued play? (yes) 1. How do you queue timed PLAY requests 2. Implementation of accurate RTP-Info for queued play 3. Very complex interaction with MUTE 4. Lack of implementer interest - Not sure what practical use cases are * RECORD....needs specification work from implementer (may need to drop) * Specifications/groups which may extend RTSP * MUTE/UNMUTE * Transport model requirements * Is persistent TCP mode required? (yes) * Is non-persistent TCP mode required? (no, will define feature tag and "Supported" header from SIP) * Define roadmap for RTSP * Interop logistics * Registration of feature tags for optional features (need to audit spec) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailman-owner@ietf.org Mon Apr 1 06:26:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18551 for ; Mon, 1 Apr 2002 06:26:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA04969 for ; Mon, 1 Apr 2002 06:26:47 -0500 (EST) Date: Mon, 1 Apr 2002 06:26:47 -0500 (EST) Message-Id: <200204011126.GAA04969@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: mmusic-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mmusic-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mmusic-web-archive@ietf.org: List Password // URL ---- -------- mmusic@ietf.org ofTV https://www1.ietf.org/mailman/options/mmusic/mmusic-web-archive@ietf.org From mmusic-admin@ietf.org Tue Apr 2 14:22:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28875 for ; Tue, 2 Apr 2002 14:22:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06943; Tue, 2 Apr 2002 14:16:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA06906 for ; Tue, 2 Apr 2002 14:16:54 -0500 (EST) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28664 for ; Tue, 2 Apr 2002 14:16:52 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 2 Apr 2002 14:16:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: Prelim copy of comedia-02 available Thread-Index: AcHaeuDv9ubf8eEdQJ2bDkDQ9AZGsw== From: "David Yon" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA06907 Subject: [MMUSIC] Prelim copy of comedia-02 available Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit http://www.dialout.net/public/ietf/draft-ietf-mmusic-sdp-comedia-02.txt The above link is an unofficial copy that I've posted for discussion purposes. The following changes have been made since comedia-01: - The assumption now is that media only ever needs a single connection, which simplifies the semantics of "direction:both". - A method to reduce the probability that "direction:both" will result in an extra connection is discussed (section 2.4). - Rohan Mahy's text about UDP and RTP/AVP is incorporated (sections 2.6 and 5.4). - "direction:reuse" has been removed. Section 4.3 covers the scenarios that reuse intended to address. - A discussion of listener and connection lifetime has been added (section 4). - The BNF has been checked for compatibility with SDPnew. I've gone through and made sure that comedia meets the SDP requirements discussed in Jeorg's slides in Minneapolis (session setup, session pause, session resume, session redirect, session parameter renegotiate, session teardown). At this point I don't see anything missing. Pause/resume/redirect/renegotiate are directly addressed in section 4. Modulo any showstopper issues brought up in the list, I'm ready to submit this as the official comedia-02 at any time. Everyone is encouraged to review and provide feedback as soon as possible. We'd like to get this into Last Call in the next week or two. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 2 16:12:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03730 for ; Tue, 2 Apr 2002 16:12:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA14023; Tue, 2 Apr 2002 16:11:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13985 for ; Tue, 2 Apr 2002 16:11:24 -0500 (EST) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03691; Tue, 2 Apr 2002 16:11:16 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32LAeZ05340; Tue, 2 Apr 2002 16:10:40 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g32LAeh29370; Tue, 2 Apr 2002 16:10:40 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Apr 2002 16:10:40 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A237@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: mmusic@ietf.org, "'megaco@ietf.org'" Date: Tue, 2 Apr 2002 16:10:41 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [MMUSIC] Silence Suppression Attribute Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org The issue of how to signal silence suppression capability keeps coming up on the Megaco list. The situation is fairly complicated: - some codecs come with a pre-defined capability for silence suppression. This capability can be invoked by the appropriate MIME type parameter as defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP transport, arguably over UDP only. - other codecs like G.711 have no such parameter, yet silence suppression is possible - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM transport only. How would people feel about allowing the a=silenceSupp parameter to be used independently of the transport type? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 2 17:33:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06168 for ; Tue, 2 Apr 2002 17:33:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18303; Tue, 2 Apr 2002 17:28:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18273 for ; Tue, 2 Apr 2002 17:28:55 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05983 for ; Tue, 2 Apr 2002 17:28:51 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g32MSlE09571; Tue, 2 Apr 2002 17:28:47 -0500 Message-Id: <200204022228.g32MSlE09571@chiron.nge.isi.edu> To: Xiaotao Wu cc: mmusic@ietf.org Subject: Re: [MMUSIC] The a=type attribute should not be session-level in SDP In-Reply-To: Your message of "Sat, 30 Mar 2002 10:42:20 EST." Date: Tue, 02 Apr 2002 17:28:47 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi, --> Xiaotao Wu writes: >One usage of the a=type attribute is to define a conference as moderated >as `a=type:moderated'. Based on the sdp-new-07, that should indicate the >use of a floor control tool and that the media tools are started so as to >"mute" new sites joining the conference. > >A common senario of a conference is, people can always see each other, but >only one people can talk at a time. That means audio is moderated but not >video. When a person join the conference, the person should mute his audio >tool but not video tool so that the other people can see him. This is common, but not the only possible scenario. >However, if the a=type attribute is defined as the session-level >attribute, both the audio tool and video tool of the person will be >muted. That's not expected. So, defining a=type attribute as session-level >attribute cannot handle this senario. I disagree. We don't want "a=type:moderated" to be specific to a particular floor control policy, rather it should allow the floor control protocol the flexibility to enforce policy as desired. The only way this is possible is if participants start with all media muted, and enable them only after they have obtained permission from the moderator. I believe sdp-new-07, and RFC 2327, are correct. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 2 18:23:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07801 for ; Tue, 2 Apr 2002 18:23:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23797; Tue, 2 Apr 2002 18:22:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA23759 for ; Tue, 2 Apr 2002 18:22:46 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07794 for ; Tue, 2 Apr 2002 18:22:45 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g32NMkp10138; Tue, 2 Apr 2002 18:22:46 -0500 Message-Id: <200204022322.g32NMkp10138@chiron.nge.isi.edu> To: "Fredrik Lindholm" cc: mmusic@ietf.org, "Elisabetta Carrara" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Wed, 20 Mar 2002 22:23:39 +0100." <005601c1d055$81f996a0$90bb3fa6@e00d05937ed1e.ietf53.cw.net> Date: Tue, 02 Apr 2002 18:22:46 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Fredrik Lindholm" writes: >To follow up the discussion at today's session, we have tried to >summarize our view of the pros and cons of placing the key >management data as a "blob" in SDP compared to splitting the >key management data into several fields. We do not claim that >this is an objective analysis, but a start of some discussion. > >Advantages and disadvantages with the key management data >as a "blob": >- It does not conform to the "normal" SDP way that every parameter > is readable and understandable by SDP. >+ The defined attributes do not depend on a specific key management > protocol, i.e. it is possible to replace one key management protocol with > another. >+ (hopefully) no more extensions need to be done to SDP in the future >+ It is easier from a message processing point of view. From a high-level > view, the "blob" is extracted and sent to the key management "function", > which will answer Accepted/ Rejected. This also implies that the key > management can be more modular and does not have to be built into the > SDP implementation. >+ Small impact on the current SDP implementation. > >Advantages and disadvantages with the key management data split >into several fields: >+ Fits into the SDP model >- The fields MUST be defined with only one key management protocol > in mind. >- If the key management protocol is changed, or another key management > protocol is used, the SDP attributes may have to be updated (as well as the > SDP implementation). >- Larger impact on the current SDP implementation >- Harder to analyze (and interop test) the key management protocol itself, > as it will be very dependent on SDP (or RTSP). > >To conclude our own thoughts, we believe that it is better from a modularity >perspective to actually use the "blob" approach, as it will give the >smallest impact on both the key management protocol and SDP. I'm not sure I agree, although you make a number of good points. How does the "blob" compare to an approach in the style of "a=fmtp" though? Generic SDP attribute, with each key management protocol defining parameters to be used within it? Fits the SDP model better, allows the key management to use the SDP parser to find its parameters, yet doesn't limit the protocol to a single key management scheme. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 2 19:13:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09068 for ; Tue, 2 Apr 2002 19:13:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26917; Tue, 2 Apr 2002 19:12:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA26858 for ; Tue, 2 Apr 2002 19:12:31 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09058 for ; Tue, 2 Apr 2002 19:12:30 -0500 (EST) Received: from orion.cs.columbia.edu (orion.cs.columbia.edu [128.59.16.21]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA05174; Tue, 2 Apr 2002 19:12:29 -0500 (EST) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by orion.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g330CSBE008150; Tue, 2 Apr 2002 19:12:28 -0500 (EST) Date: Tue, 2 Apr 2002 19:12:28 -0500 (EST) From: Xiaotao Wu To: Colin Perkins cc: Subject: Re: [MMUSIC] The a=type attribute should not be session-level in SDP In-Reply-To: <200204022228.g32MSlE09571@chiron.nge.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > >A common senario of a conference is, people can always see each other, but > >only one people can talk at a time. That means audio is moderated but not > >video. When a person join the conference, the person should mute his audio > >tool but not video tool so that the other people can see him. > > This is common, but not the only possible scenario. > > >However, if the a=type attribute is defined as the session-level > >attribute, both the audio tool and video tool of the person will be > >muted. That's not expected. So, defining a=type attribute as session-level > >attribute cannot handle this senario. > > I disagree. We don't want "a=type:moderated" to be specific to a particular > floor control policy, rather it should allow the floor control protocol the > flexibility to enforce policy as desired. The only way this is possible is > if participants start with all media muted, and enable them only after they > have obtained permission from the moderator. Then the moderator will be very busy in a large conference. Think about a moderated conference with audio and whiteboard. Everybody is allowed to speak but only one people can draw on the board so that the figure will not get messed up. If the conference server invite 500 people to join the conference, the moderator of the conference need to grant permission 501 times when the conference starts. (500 for audio and 1 for whiteboard). If we allow the a=type:moderated to be media level (only applied to the whiteboard), the moderator will only need do the grant permission once to the person who can draw on the whiteboard. Why not allow the a=type:moderated can be both session level or media level attribute? -Xiaotao > > I believe sdp-new-07, and RFC 2327, are correct. > > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 2 22:04:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12941 for ; Tue, 2 Apr 2002 22:04:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06823; Tue, 2 Apr 2002 22:01:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA06782 for ; Tue, 2 Apr 2002 22:01:16 -0500 (EST) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12911 for ; Tue, 2 Apr 2002 22:01:13 -0500 (EST) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g33316D13909; Tue, 2 Apr 2002 22:01:06 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204030301.g33316D13909@purple.nge.isi.edu> To: Xiaotao Wu cc: mmusic@ietf.org Subject: Re: [MMUSIC] The a=type attribute should not be session-level in SDP In-Reply-To: Your message of "Tue, 02 Apr 2002 19:12:28 EST." Date: Tue, 02 Apr 2002 22:01:06 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> Xiaotao Wu writes: >> >A common senario of a conference is, people can always see each other, but >> >only one people can talk at a time. That means audio is moderated but not >> >video. When a person join the conference, the person should mute his audio >> >tool but not video tool so that the other people can see him. >> >> This is common, but not the only possible scenario. >> >> >However, if the a=type attribute is defined as the session-level >> >attribute, both the audio tool and video tool of the person will be >> >muted. That's not expected. So, defining a=type attribute as session-level >> >attribute cannot handle this senario. >> >> I disagree. We don't want "a=type:moderated" to be specific to a particular >> floor control policy, rather it should allow the floor control protocol the >> flexibility to enforce policy as desired. The only way this is possible is >> if participants start with all media muted, and enable them only after they >> have obtained permission from the moderator. > >Then the moderator will be very busy in a large conference. Think about a >moderated conference with audio and whiteboard. Everybody is allowed to >speak but only one people can draw on the board so that the figure will >not get messed up. If the conference server invite 500 people to join the >conference, the moderator of the conference need to grant permission 501 >times when the conference starts. (500 for audio and 1 for whiteboard). >If we allow the a=type:moderated to be media level (only applied to the >whiteboard), the moderator will only need do the grant permission once to >the person who can draw on the whiteboard. > >Why not allow the a=type:moderated can be both session level or media >level attribute? It's possible, but it's a non-backwards compatible change. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 01:55:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17821 for ; Wed, 3 Apr 2002 01:55:24 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28241; Wed, 3 Apr 2002 01:54:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28196 for ; Wed, 3 Apr 2002 01:54:38 -0500 (EST) Received: from mail.redlinecommunications.ro (root@gate.redlinecommunications.ro [213.154.146.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17810 for ; Wed, 3 Apr 2002 01:54:34 -0500 (EST) Received: from dan (dan.softtel.ro [192.168.0.27]) by mail.redlinecommunications.ro (8.11.4/8.11.4) with SMTP id g336s6q01139; Wed, 3 Apr 2002 09:54:08 +0300 Message-ID: <004201c1dadb$d48714c0$1b00a8c0@softtel.ro> From: "Dan Firac" To: "Tom-PT Taylor" Cc: References: <4D79C746863DD51197690002A52CDA0001E8A237@zcard0kc.ca.nortel.com> Subject: Re: [MMUSIC] Silence Suppression Attribute Date: Wed, 3 Apr 2002 09:50:21 +0300 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit It's a very good ideea. Anyway, why this attribute was defined for ATM transport type only? Silence suppression, as you pointed below, is an attribute of a codec and has nothing to do with transport. Dan Firac, Software Engineer, RedlineCommunications, Romania. ----- Original Message ----- From: "Tom-PT Taylor" To: ; Sent: Wednesday, April 03, 2002 12:10 AM Subject: [MMUSIC] Silence Suppression Attribute > The issue of how to signal silence suppression capability keeps coming up on > the Megaco list. The situation is fairly complicated: > - some codecs come with a pre-defined capability for silence suppression. > This capability can be invoked by the appropriate MIME type parameter as > defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP > transport, arguably over UDP only. > - other codecs like G.711 have no such parameter, yet silence suppression > is possible > - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM > transport only. > > How would people feel about allowing the a=silenceSupp parameter to be used > independently of the transport type? > > Tom Taylor > taylor@nortelnetworks.com > Ph. +1 613 736 0961 (ESN 396 1490) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 03:46:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27344 for ; Wed, 3 Apr 2002 03:46:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04781; Wed, 3 Apr 2002 03:44:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04750 for ; Wed, 3 Apr 2002 03:44:54 -0500 (EST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27313 for ; Wed, 3 Apr 2002 03:44:51 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g338iss7008412 for ; Wed, 3 Apr 2002 10:44:54 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Apr 03 10:42:52 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 10:44:48 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4133@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Wed, 3 Apr 2002 10:44:08 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > -----Original Message----- > From: Colin Perkins [mailto:csp@isi.edu] > > --> "Fredrik Lindholm" writes: > > > >To conclude our own thoughts, we believe that it is better > from a modularity > >perspective to actually use the "blob" approach, as it will give the > >smallest impact on both the key management protocol and SDP. > > I'm not sure I agree, although you make a number of good > points. How does > the "blob" compare to an approach in the style of "a=fmtp" > though? Generic > SDP attribute, with each key management protocol defining > parameters to be > used within it? Fits the SDP model better, allows the key > management to use > the SDP parser to find its parameters, yet doesn't limit the > protocol to a > single key management scheme. > Using the SDP parser is not something I would recommend. First of all, the key management protocols (almost all) have already a built in parser (so it is there, and something similar must still be in place to verify that the attributes are of valid types etc.). Secondly, the protocol is generally defined in a way that the MAC/ Signature, protecting the data that are sent, are computed over the entire key management message (which is built up by a set of pre-defined payloads). If you then would like to split the key management message into sub parts and provide these as some values in SDP, the key management protocol still have to create the set of payloads and compute the MAC, before it can be split into subparts. When an SDP message arrives, the SDP parser must first parse the set of attributes, send it to the key management, which then must merge these together into payloads in order to be able to verify the MAC/Signature. This is not very good from a security point of view, as you would like to verify the MAC/Signature as soon as possible. I think this approach would create too much double work unless the parameter is more or less a "blob". I think the approach we have chosen are very equal to the "fmtp", or? The only description of fmtp that I found said: "This attribute allows parameters that are specific to a particular format to be conveyed in a way that SDP doesn't have to understand them.". As I see it, we have almost the exact same approach, except that we have it spread out on three different lines. a=fmtp: To compare: a=keymgmt-prot: // this is equal to a=keymgmt-data: // this is equal to the format specific data a=keymgmt-auth: // this is equal/subpart to/of the format specific data So we could of course think of merging these into one line and define: a=keymgmt: and using a similar description to fmtp: This attribute allows parameters that are specific to a particular key management protocol to be conveyed in a way that SDP doesn't have to understand them. Key management specific parameters may be any set of parameters required to be conveyed by SDP and given unchanged to the key management protocol that will use this format. If we use this approach, I'll guess we don't have to worry that much about the "blob" thing, as each key management protocol in practice can choose either way that is appropriate. Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 05:41:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28793 for ; Wed, 3 Apr 2002 05:41:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10962; Wed, 3 Apr 2002 05:39:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10931 for ; Wed, 3 Apr 2002 05:39:26 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28647 for ; Wed, 3 Apr 2002 05:39:17 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g33Acu3G029362; Wed, 3 Apr 2002 12:38:56 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id MAA01127; Wed, 3 Apr 2002 12:38:56 +0200 Message-ID: <3CAADBC0.3090504@era.ericsson.se> Date: Wed, 03 Apr 2002 12:38:56 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: philippe.gentric@philips.com CC: IETF MMUSIC WG Subject: Re: [MMUSIC] MoMs from RTSP lunch meeting at IETF References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Philippe, Yes, Remote camera control would be one possible application of such protocoll or extensions. /Magnus philippe.gentric@philips.com wrote: > > This 3+1 dimension stuff, would it be meant/suitable for kind of > remote camera control ? > > > Philippe Gentric > Software Architect > Philips MP4Net > philippe.gentric@philips.com > http://www.mpeg-4.philips.com > > > > Magnus Westerlund > Sent by: mmusic-admin@ietf.org > > 03/25/2002 16:37 > > > To: IETF MMUSIC WG > cc: (bcc: Philippe Gentric/LIM/CE/PHILIPS) > Subject: [MMUSIC] MoMs from RTSP lunch meeting at IETF > > Classification: > > > > > Hi > > Here comes the minutes of meeting from last weeks RTSP lunch meeting. > > Regards > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/T/VA > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > RTSP Lunch meeting Thursday 21 march 2002 11.40-13.00 at the 53rd IETF > > approx 15 participants. > > 1. Interop discussion > > - The previous RTSP interop seem to have lacked a proper test plan. > > - We should look at both HTTP and SIP interop work to get a good > opinion what is > a good way to do it. > > - We may have to come to some agreements on what to disclose of the > results of > an interop. > > - Propose to do offline testing before any event to reach a common > level of > interoperability. > > - May create/compile a document with RTSP traces that are compliant > for testing. > > 2. JPEG-2000 Internet protocol > > Mark Wood made a short presentation which contained: - Use cases and > possibilities with JPEG-2000 - requirements on a control protocol - > The data > transport may vary and is not finished. - Two mode of operations, server > controlled and client controlled. Requested input on: Is a RTSP style > protocol the > right idea? See message to mmusic for initial document idea. > > Comments: - Such a control protocol could be generalized beyond > JPEG-2000. - > Should not create two protocol that are very similar. - This problems > includes > navigation/control in up to 4 (3 spacial + temporal) or more > dimensions(e.g. > IR,Xray, Radar). - It could be a possibility to decouple the temporal > control > (RTSP) from the spatial control (new protocol). - The most probable > initial > transport will be TCP for the data plane. - When combining temporal > and spatial > control there might be aggregation problems. - This problem is worth > further > discussion and work. Use the MMUSIC mailing list for discussion. > > 3. CATS > > Interested in the possibility to do Text To Speech (TTS) and Automatic > Speech > Recognition (ASR) control with RTSP. Do TTS to and control that with > PLAY. May > also use RECORD for ASR and also streaming results back to the sender. > > 4. RTSP extension > > - The work with RTSP to draft standard should not be effected by > extensions. - > All extensions should be reasonable and fit RTSP's model. - Avoid > SIP's Info > decease by not overloading a general method. - We should also carefully > consider the interaction of RTSP middle boxes. - The protocol capability > discovery also needs to be consider by applications using extensions. > There > are basically 3 levels that can work. > 1. Demand a functionality and be certain by checking it previous to use. > 2. Try functionality and receive notification if it does not work. > But the > application can handle the lack of the functionality. > 3. Do not care if functionality works or not. > > - Is there need for adding a more elaborated scope description for > RTSP? - There > might be need to clarify how proxies shall handle unknown methods. - > In most > extensions requiring new functionality new methods should be created. > This > will avoid having multiple levels of multiplexing, which could be the > result > if SET_PARAMETER parameters is used to create a extension. > SET_PARAMETER shall > not be used as a tunneling method. > > Due to lack of time no of the direct RTSP issues was covered in this > meeting. > > > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 18:17:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18457 for ; Wed, 3 Apr 2002 18:17:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04424; Wed, 3 Apr 2002 18:13:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04393 for ; Wed, 3 Apr 2002 18:13:00 -0500 (EST) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18417 for ; Wed, 3 Apr 2002 18:12:56 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g33NCTKR006026 for ; Wed, 3 Apr 2002 15:12:29 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g33NCSxu025005 for ; Wed, 3 Apr 2002 15:12:28 -0800 Date: Wed, 3 Apr 2002 15:15:19 -0800 (Pacific Standard Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: "Conference" header Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, Section 12.10 defines a "Conference" header. We don't implement this, and I don't see enough information in this header where we could implement it if we wanted to. Is anyone using this, and if so, how? Thanks Rob _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 18:30:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18741 for ; Wed, 3 Apr 2002 18:30:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04783; Wed, 3 Apr 2002 18:22:37 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA04737 for ; Wed, 3 Apr 2002 18:22:33 -0500 (EST) Received: from purple.nge.isi.edu (wireless101.east.isi.edu [65.114.168.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18604 for ; Wed, 3 Apr 2002 18:22:29 -0500 (EST) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g33NMW19000718; Wed, 3 Apr 2002 18:22:33 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204032322.g33NMW19000718@purple.nge.isi.edu> To: "Dan Firac" cc: "Tom-PT Taylor" , mmusic@ietf.org Subject: Re: [MMUSIC] Silence Suppression Attribute In-Reply-To: Your message of "Wed, 03 Apr 2002 09:50:21 +0300." <004201c1dadb$d48714c0$1b00a8c0@softtel.ro> Date: Wed, 03 Apr 2002 18:22:32 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org What would be the scenario where the new attribute is used? Colin --> "Dan Firac" writes: >It's a very good ideea. >Anyway, why this attribute was defined for ATM transport type only? >Silence suppression, as you pointed below, is an attribute of a codec >and has nothing to do with transport. > >Dan Firac, >Software Engineer, >RedlineCommunications, >Romania. > > > > >----- Original Message ----- >From: "Tom-PT Taylor" >To: ; >Sent: Wednesday, April 03, 2002 12:10 AM >Subject: [MMUSIC] Silence Suppression Attribute > > >> The issue of how to signal silence suppression capability keeps coming up >on >> the Megaco list. The situation is fairly complicated: >> - some codecs come with a pre-defined capability for silence suppression. >> This capability can be invoked by the appropriate MIME type parameter as >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP >> transport, arguably over UDP only. >> - other codecs like G.711 have no such parameter, yet silence suppression >> is possible >> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM >> transport only. >> >> How would people feel about allowing the a=silenceSupp parameter to be >used >> independently of the transport type? >> >> Tom Taylor >> taylor@nortelnetworks.com >> Ph. +1 613 736 0961 (ESN 396 1490) >> >> >> _______________________________________________ >> 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 mmusic-admin@ietf.org Wed Apr 3 18:44:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19156 for ; Wed, 3 Apr 2002 18:44:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06346; Wed, 3 Apr 2002 18:42:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06311 for ; Wed, 3 Apr 2002 18:42:33 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19113 for ; Wed, 3 Apr 2002 18:42:29 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g33Ng2S06755 for ; Wed, 3 Apr 2002 18:42:02 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Apr 2002 18:42:04 -0500 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A247@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Colin Perkins'" , Dan Firac Cc: mmusic@ietf.org Subject: RE: [MMUSIC] Silence Suppression Attribute Date: Wed, 3 Apr 2002 18:42:02 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org The caller supports G.711 with voice activity detection and silence suppression and would like to make that offer. There is no PCM parameter indicating this mode of operation. -----Original Message----- From: Colin Perkins [mailto:csp@isi.edu] Sent: Wednesday, April 03, 2002 6:23 PM To: Dan Firac Cc: Taylor, Tom-PT [CAR:B800:EXCH]; mmusic@ietf.org Subject: Re: [MMUSIC] Silence Suppression Attribute What would be the scenario where the new attribute is used? Colin --> "Dan Firac" writes: >It's a very good ideea. >Anyway, why this attribute was defined for ATM transport type only? >Silence suppression, as you pointed below, is an attribute of a codec >and has nothing to do with transport. > >Dan Firac, >Software Engineer, >RedlineCommunications, >Romania. > > > > >----- Original Message ----- >From: "Tom-PT Taylor" >To: ; >Sent: Wednesday, April 03, 2002 12:10 AM >Subject: [MMUSIC] Silence Suppression Attribute > > >> The issue of how to signal silence suppression capability keeps coming up >on >> the Megaco list. The situation is fairly complicated: >> - some codecs come with a pre-defined capability for silence suppression. >> This capability can be invoked by the appropriate MIME type parameter as >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP >> transport, arguably over UDP only. >> - other codecs like G.711 have no such parameter, yet silence suppression >> is possible >> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM >> transport only. >> >> How would people feel about allowing the a=silenceSupp parameter to be >used >> independently of the transport type? >> >> Tom Taylor >> taylor@nortelnetworks.com >> Ph. +1 613 736 0961 (ESN 396 1490) >> >> >> _______________________________________________ >> 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 mmusic-admin@ietf.org Wed Apr 3 18:48:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19221 for ; Wed, 3 Apr 2002 18:48:15 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06527; Wed, 3 Apr 2002 18:46:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06492 for ; Wed, 3 Apr 2002 18:46:14 -0500 (EST) Received: from purple.nge.isi.edu (wireless101.east.isi.edu [65.114.168.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19175 for ; Wed, 3 Apr 2002 18:46:10 -0500 (EST) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g33NkC19000756; Wed, 3 Apr 2002 18:46:12 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204032346.g33NkC19000756@purple.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Wed, 03 Apr 2002 10:44:08 +0200." <0DAEDF148988D411BB980008C7E65D2E04FE4133@esealnt416> Date: Wed, 03 Apr 2002 18:46:12 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org I think we need to step back, and evaluate what we're trying to solve here. If the key management attributes are to be general purpose, and can be used with a range of key exchange protocols, then I would argue that they should be visible to SDP and have well defined semantics at the SDP level. In this case, I'd expect to see something like: a=key-mgnt:mikey algorithm=aes key=... mac=... for an appropriate set of generic key-exchange/authentication parameters. In this case, I'd expect another keying protocol to use mostly the same parameters, and to pick them up from the SDP. If, however, they're opaque and used solely by a particular protocol, then I don't see the advantage of trying to make the attribute generic. Why use a=keymgmt-prot:MIKEY a=keymgmt-data: instead of a=mikey: when non-MIKEY speakers won't understand the attribute in either case? Colin --> "Fredrik Lindholm (ERA)" writes: >> -----Original Message----- >> From: Colin Perkins [mailto:csp@isi.edu] >> >> --> "Fredrik Lindholm" writes: > >> > >> >To conclude our own thoughts, we believe that it is better >> from a modularity >> >perspective to actually use the "blob" approach, as it will give the >> >smallest impact on both the key management protocol and SDP. >> >> I'm not sure I agree, although you make a number of good >> points. How does >> the "blob" compare to an approach in the style of "a=fmtp" >> though? Generic >> SDP attribute, with each key management protocol defining >> parameters to be >> used within it? Fits the SDP model better, allows the key >> management to use >> the SDP parser to find its parameters, yet doesn't limit the >> protocol to a >> single key management scheme. >> > >Using the SDP parser is not something I would recommend. >First of all, the key management protocols (almost all) >have already a built in parser (so it is there, and >something similar must still be in place to verify that >the attributes are of valid types etc.). Secondly, the >protocol is generally defined in a way that the MAC/ >Signature, protecting the data that are sent, are >computed over the entire key management message (which >is built up by a set of pre-defined payloads). > >If you then would like to split the key management message >into sub parts and provide these as some values in SDP, the >key management protocol still have to create the set of >payloads and compute the MAC, before it can be split into >subparts. When an SDP message arrives, the SDP parser must >first parse the set of attributes, send it to the key >management, which then must merge these together into >payloads in order to be able to verify the MAC/Signature. >This is not very good from a security point of view, as >you would like to verify the MAC/Signature as soon as >possible. I think this approach would create too much double >work unless the parameter is more or less a "blob". > >I think the approach we have chosen are very equal to the >"fmtp", or? The only description of fmtp that I found said: >"This attribute allows parameters that are specific to a >particular format to be conveyed in a way that SDP doesn't >have to understand them.". As I see it, we have almost the >exact same approach, except that we have it spread out on >three different lines. > >a=fmtp: > >To compare: > >a=keymgmt-prot: // this is equal to >a=keymgmt-data: // this is equal to the format specific data >a=keymgmt-auth: // this is equal/subpart to/of the format specific data > >So we could of course think of merging these into one line >and define: >a=keymgmt: > >and using a similar description to fmtp: > >This attribute allows parameters that are specific to a >particular key management protocol to be conveyed in a way >that SDP doesn't have to understand them. Key management >specific parameters may be any set of parameters required >to be conveyed by SDP and given unchanged to the key >management protocol that will use this format. > >If we use this approach, I'll guess we don't have to worry >that much about the "blob" thing, as each key management >protocol in practice can choose either way that is >appropriate. > >Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 18:58:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19378 for ; Wed, 3 Apr 2002 18:58:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06861; Wed, 3 Apr 2002 18:56:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA06810 for ; Wed, 3 Apr 2002 18:56:19 -0500 (EST) Received: from purple.nge.isi.edu (wireless101.east.isi.edu [65.114.168.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19352 for ; Wed, 3 Apr 2002 18:56:15 -0500 (EST) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g33NuL19000845; Wed, 3 Apr 2002 18:56:21 -0500 (EST) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204032356.g33NuL19000845@purple.nge.isi.edu> To: "Tom-PT Taylor" cc: Dan Firac , mmusic@ietf.org Subject: Re: [MMUSIC] Silence Suppression Attribute In-Reply-To: Your message of "Wed, 03 Apr 2002 18:42:02 EST." <4D79C746863DD51197690002A52CDA0001E8A247@zcard0kc.ca.nortel.com> Date: Wed, 03 Apr 2002 18:56:21 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org If you're using RTP, it's assumed that silence suppression is possible (and since receivers have to cope with packet loss anyway, this doesn't add any significant complexity). Colin --> "Tom-PT Taylor" writes: >The caller supports G.711 with voice activity detection and silence >suppression and would like to make that offer. There is no PCM parameter >indicating this mode of operation. > >-----Original Message----- >From: Colin Perkins [mailto:csp@isi.edu] >Sent: Wednesday, April 03, 2002 6:23 PM >To: Dan Firac >Cc: Taylor, Tom-PT [CAR:B800:EXCH]; mmusic@ietf.org >Subject: Re: [MMUSIC] Silence Suppression Attribute > > >What would be the scenario where the new attribute is used? >Colin > > >--> "Dan Firac" writes: >>It's a very good ideea. >>Anyway, why this attribute was defined for ATM transport type only? >>Silence suppression, as you pointed below, is an attribute of a codec >>and has nothing to do with transport. >> >>Dan Firac, >>Software Engineer, >>RedlineCommunications, >>Romania. >> >> >> >> >>----- Original Message ----- >>From: "Tom-PT Taylor" >>To: ; >>Sent: Wednesday, April 03, 2002 12:10 AM >>Subject: [MMUSIC] Silence Suppression Attribute >> >> >>> The issue of how to signal silence suppression capability keeps coming up >>on >>> the Megaco list. The situation is fairly complicated: >>> - some codecs come with a pre-defined capability for silence >suppression. >>> This capability can be invoked by the appropriate MIME type parameter as >>> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP >>> transport, arguably over UDP only. >>> - other codecs like G.711 have no such parameter, yet silence >suppression >>> is possible >>> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM >>> transport only. >>> >>> How would people feel about allowing the a=silenceSupp parameter to be >>used >>> independently of the transport type? >>> >>> Tom Taylor >>> taylor@nortelnetworks.com >>> Ph. +1 613 736 0961 (ESN 396 1490) >>> >>> >>> _______________________________________________ >>> 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 mmusic-admin@ietf.org Wed Apr 3 19:30:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19888 for ; Wed, 3 Apr 2002 19:30:17 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08768; Wed, 3 Apr 2002 19:28:45 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA08735 for ; Wed, 3 Apr 2002 19:28:42 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19850 for ; Wed, 3 Apr 2002 19:28:35 -0500 (EST) Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id TAA12005; Wed, 3 Apr 2002 19:28:37 -0500 (EST) Received: from cs.columbia.edu (cta.cs.columbia.edu [128.59.19.46]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g340SaPm026054 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Apr 2002 19:28:37 -0500 (EST) Message-ID: <3CAB9E13.F5C986EF@cs.columbia.edu> Date: Wed, 03 Apr 2002 19:28:03 -0500 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Lanphier CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: "Conference" header 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit This was meant to tie together a conference (e.g., SIP-established) and a recording. I agree that it is underspecified to be useful, and it's not clear such a mechanism is needed at all. Rob Lanphier wrote: > > Hi all, > > Section 12.10 defines a "Conference" header. We don't implement this, and > I don't see enough information in this header where we could implement it > if we wanted to. Is anyone using this, and if so, how? > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 21:13:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21343 for ; Wed, 3 Apr 2002 21:13:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13637; Wed, 3 Apr 2002 21:06:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA13580 for ; Wed, 3 Apr 2002 21:06:17 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21257; Wed, 3 Apr 2002 21:06:13 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g3424bj75993; Wed, 3 Apr 2002 18:04:37 -0800 (PST) (envelope-from casner@packetdesign.com) Date: Wed, 3 Apr 2002 18:05:44 -0800 (PST) From: Stephen Casner To: Tom-PT Taylor cc: , Subject: Re: [MMUSIC] Silence Suppression Attribute In-Reply-To: <200204032356.g33NuL19000845@purple.nge.isi.edu> Message-ID: <20020403165246.Q48839-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This reply is both to this thread in MMUSIC and to one from the Megaco list titled "Local/Remote descriptors and Permanent terminations" that Tom cc'd to me. On Tue, 2 Apr 2002, Tom-PT Taylor wrote: > The issue of how to signal silence suppression capability keeps coming up on > the Megaco list. The situation is fairly complicated: > - some codecs come with a pre-defined capability for silence suppression. > This capability can be invoked by the appropriate MIME type parameter as > defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP > transport, arguably over UDP only. > - other codecs like G.711 have no such parameter, yet silence suppression > is possible As Colin said, for all RTP audio codecs, silence suppression is assumed to be enabled. Therefore, we clearly do not need an attribute to enable silence suppression. We may or may not need some attribute to disable silence suppression, but I don't know what scenario requires that. A related discussion occurred on the AVT list in November, 2001, with the subject line "Reg draft-ietf-avt-rtp-mime-05.txt". At that time, the sense I got was that some implementations could not handle receiving an RTP stream with silence suppressed. My reaction to that was pretty strong: Silence suppression has been a fundamental part of RTP since the beginning. That is why the RTP header carries both a sequence number and a timestamp. Suppressing silence is one of the primary reasons for going to packet transmission of voice in the first place. Furthermore, even if the transmitter does not suppress silence, the receiver must be prepared to handle the situation where there is a frame time for which no packet is present because packets may be lost. Any implementation that has not been sufficiently developed to recover reasonably to such a situation should be flatly rejected. Can you explain a situation that is a valid justification for disabling silence suppression? > - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM > transport only. > > How would people feel about allowing the a=silenceSupp parameter to be used > independently of the transport type? It may have been a mistake to include the a=silenceSupp attribute for ATM without considering the problem more generally. I suspect that RFC 3108 did not get much attention in MMUSIC because many of the participants don't care much about ATM. On Wed, 3 Apr 2002, Tom-PT Taylor wrote: > To summarize: we are trying to define how to indicate that silence > suppression is desired for a given audio flow. More specifically, to indicate when silence suppression is NOT desired. > We could do it through an > a=silenceSupp attribute, through codec-specific a=fmtp: parameters, or > implicitly by specifying the Comfort Noise codec as an alternative. We can't add fmtp parameters to an existing payload format after the fact without incurring backwards compatibility problems. It is reasonable to interpret the inclusion of the Comfort Noise codec as a desire or willingness to suppress silence. However, it is NOT reasonable to interpret the omission of the Comfort Noise codec as an indication that silence will not be suppressed. > I think it's quite clear that we do NOT want to tie silence suppression to > the TDM package. What are the requirements for enabling or disabling silence suppression when using TDM? What does silence suppression mean when using TDM? > The cleanest way would be to ensure that every codec where silence > suppression might apply has a silence suppression parameter. For RTP, this > requires revisiting draft-ietf-avt-rtp-mime-06.txt, which is currently in > IETF Last Call. As I said above, adding such a parameter would create backwards compatibility problems. It's not just a matter of definition. The parameters belong to the payload format specification, not to the MIME registration. > Not sure what we do about ATM: RFC 3108 defines a profile > that just picks up the RTP mappings, so maybe it would also pick up the > parameters defined in the MIME type registrations and payload format > descriptions. I find this whole area murky because theoretically there > should be new MIME type registrations for each transport in order to reuse > the profiles in SDP. It should only be necessary to revise the MIME registrations for a new transport if additional parameters, encoding considerations, etc, need to be defined for that new transport. Many of the MIME registrations for RTP encodings only cover RTP transport and not email/http transport because no file format has been defined for those encodings. > A second possibility is to define the a=silenceSupp attribute for all > transports, but specify that it takes second priority to a=fmtp parameters > where these are defined. This is probably the most practical route. At MMUSIC in Minneapolis, the need for a "generic format parameters" attribute was discussed, triggered by the need for a particular payload type number to indicate the presence of voiceband data. This would serve (at least at a syntactical level) as a place to put a "please do not suppress silence" parameter, but since it is ignorable, it would not guarantee that silence would not be suppressed. As I pointed out above, UDP does not guarantee to deliver a packet for every frame time in any case. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 3 23:26:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25367 for ; Wed, 3 Apr 2002 23:26:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20709; Wed, 3 Apr 2002 23:21:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA20678 for ; Wed, 3 Apr 2002 23:21:13 -0500 (EST) Received: from mailman.packetdesign.com (dns.packetdesign.com [65.192.41.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25339 for ; Wed, 3 Apr 2002 23:21:09 -0500 (EST) Received: from ash.packetdesign.com (ash.packetdesign.com [192.168.0.243]) by mailman.packetdesign.com (8.11.6/8.11.6) with ESMTP id g344KHj77832; Wed, 3 Apr 2002 20:20:17 -0800 (PST) (envelope-from casner@acm.org) Date: Wed, 3 Apr 2002 20:21:24 -0800 (PST) From: Stephen Casner To: Colin Perkins cc: "Fredrik Lindholm (ERA)" , , "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: <200204032346.g33NkC19000756@purple.nge.isi.edu> Message-ID: <20020403201958.A48839-100000@ash.packetdesign.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org On Wed, 3 Apr 2002, Colin Perkins wrote: > If, however, they're opaque and used solely by a particular protocol, then > I don't see the advantage of trying to make the attribute generic. Why use > a=keymgmt-prot:MIKEY > a=keymgmt-data: > instead of > a=mikey: > when non-MIKEY speakers won't understand the attribute in either case? Well, it seems a bit dangerous to insert the namespace of key management protocols into the SDP attribute namespace. -- Steve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 4 02:19:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05949 for ; Thu, 4 Apr 2002 02:19:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09284; Thu, 4 Apr 2002 02:18:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09246 for ; Thu, 4 Apr 2002 02:18:37 -0500 (EST) Received: from mxout2.netvision.net.il (mxout2.netvision.net.il [194.90.9.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05907; Thu, 4 Apr 2002 02:18:33 -0500 (EST) Received: from nt-mail.radvision.com ([212.143.185.30]) by mxout2.netvision.net.il (iPlanet Messaging Server 5.1 (built Sep 5 2001)) with ESMTP id <0GU100G998A3KE@mxout2.netvision.net.il>; Thu, 04 Apr 2002 10:18:04 +0300 (IDT) Received: by nt-mail.radvision.com with Internet Mail Service (5.5.2650.21) id <21HN1QJM>; Thu, 04 Apr 2002 10:16:52 +0300 Content-return: allowed Date: Thu, 04 Apr 2002 10:16:50 +0300 From: Dan Elbert To: "'Tom-PT Taylor'" , mmusic@ietf.org, "'megaco@ietf.org'" Message-id: MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Content-Transfer-Encoding: 7BIT Subject: [MMUSIC] RE: [Megaco] Silence Suppression Attribute Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7BIT I think is a good idea By the way, if an attribute is registred for use in SDP I don't think there is a scope limitation, anybody can effectively use it. Dan Elbert RADVISION -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, April 03, 2002 12:11 AM To: mmusic@ietf.org; 'megaco@ietf.org' Subject: [Megaco] Silence Suppression Attribute The issue of how to signal silence suppression capability keeps coming up on the Megaco list. The situation is fairly complicated: - some codecs come with a pre-defined capability for silence suppression. This capability can be invoked by the appropriate MIME type parameter as defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP transport, arguably over UDP only. - other codecs like G.711 have no such parameter, yet silence suppression is possible - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM transport only. How would people feel about allowing the a=silenceSupp parameter to be used independently of the transport type? Tom Taylor taylor@nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490) _______________________________________________ Megaco mailing list Megaco@ietf.org https://www1.ietf.org/mailman/listinfo/megaco _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 4 02:44:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06246 for ; Thu, 4 Apr 2002 02:44:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10516; Thu, 4 Apr 2002 02:42:01 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA10481 for ; Thu, 4 Apr 2002 02:41:59 -0500 (EST) Received: from mail.redlinecommunications.ro (root@gate.redlinecommunications.ro [213.154.146.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06198 for ; Thu, 4 Apr 2002 02:41:41 -0500 (EST) Received: from dan (dan.softtel.ro [192.168.0.27]) by mail.redlinecommunications.ro (8.11.4/8.11.4) with SMTP id g347evx00571; Thu, 4 Apr 2002 10:40:57 +0300 Message-ID: <004701c1dbab$83e50740$1b00a8c0@softtel.ro> From: "Dan Firac" To: "Colin Perkins" Cc: References: <200204032322.g33NMW19000718@purple.nge.isi.edu> Subject: Re: [MMUSIC] Silence Suppression Attribute Date: Thu, 4 Apr 2002 10:37:03 +0300 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit It's about user preferences. Scenario: If the user prefers to DISABLE Silence Suppresion in order to acheive higher audio quality, then the SDP composed by its phone should express this wish. Further pros: 1) Silence suppression it's a PARAMETER for many codecs, and I think it should be present in SDP offers/answers. 2) When the remote end is not well tuned (ex: volumes), the VAD on the remote end may brutally cut the speech, so our local user will not know/feel if there were loses or the remote user stopped speaking. 3) The same thing happens when the local user has G723 without AnnexA (VAD), G729 without AnnexB, and would want to force the remote end to use a codec without silence suppression. Points 2) and 3) are about gaining some quality. You are right, RTP assumes silence suppression and all the scenarios (including the above scenarios) are working without negotiating Silence Suppression. But is the obtained quality the best quality that can be acheived????? I think the user should decide it and the SDP should offer him a mechanism (at least, optional) to express his preferences. Best regards, Dan Firac, Software Engineer, RedlineCommunications, Romania. ----- Original Message ----- From: "Colin Perkins" To: "Dan Firac" Cc: "Tom-PT Taylor" ; Sent: Thursday, April 04, 2002 2:22 AM Subject: Re: [MMUSIC] Silence Suppression Attribute > What would be the scenario where the new attribute is used? > Colin > > > --> "Dan Firac" writes: > >It's a very good ideea. > >Anyway, why this attribute was defined for ATM transport type only? > >Silence suppression, as you pointed below, is an attribute of a codec > >and has nothing to do with transport. > > > >Dan Firac, > >Software Engineer, > >RedlineCommunications, > >Romania. > > > > > > > > > >----- Original Message ----- > >From: "Tom-PT Taylor" > >To: ; > >Sent: Wednesday, April 03, 2002 12:10 AM > >Subject: [MMUSIC] Silence Suppression Attribute > > > > > >> The issue of how to signal silence suppression capability keeps coming up > >on > >> the Megaco list. The situation is fairly complicated: > >> - some codecs come with a pre-defined capability for silence suppression. > >> This capability can be invoked by the appropriate MIME type parameter as > >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to RTP > >> transport, arguably over UDP only. > >> - other codecs like G.711 have no such parameter, yet silence suppression > >> is possible > >> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM > >> transport only. > >> > >> How would people feel about allowing the a=silenceSupp parameter to be > >used > >> independently of the transport type? > >> > >> Tom Taylor > >> taylor@nortelnetworks.com > >> Ph. +1 613 736 0961 (ESN 396 1490) > >> > >> > >> _______________________________________________ > >> 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 mmusic-admin@ietf.org Thu Apr 4 11:31:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21618 for ; Thu, 4 Apr 2002 11:31:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12748; Thu, 4 Apr 2002 11:27:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12667 for ; Thu, 4 Apr 2002 11:27:30 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21380 for ; Thu, 4 Apr 2002 11:27:25 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34GRR3G012560 for ; Thu, 4 Apr 2002 18:27:27 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Apr 04 18:13:41 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBS0WDQ>; Thu, 4 Apr 2002 18:11:43 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE413B@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Thu, 4 Apr 2002 10:15:15 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > > I think we need to step back, and evaluate what we're trying > to solve here. > If the key management attributes are to be general purpose, > and can be used > with a range of key exchange protocols, then I would argue > that they should > be visible to SDP and have well defined semantics at the SDP > level. In this > case, I'd expect to see something like: > > a=key-mgnt:mikey algorithm=aes key=... mac=... > > for an appropriate set of generic key-exchange/authentication > parameters. > In this case, I'd expect another keying protocol to use > mostly the same > parameters, and to pick them up from the SDP. Using almost the same reasons, I would argue the opposite, as it is very hard to find a set of good attributes that can be used with a variety of protocols (as the key mgmt protocols have very different properties). It is also not clear how these attributes could be used in the key mgmt response, as it might (in one extreme) be a message where everything are encrypted. > > If, however, they're opaque and used solely by a particular > protocol, then > I don't see the advantage of trying to make the attribute > generic. Why use > a=keymgmt-prot:MIKEY > a=keymgmt-data: > instead of > a=mikey: > when non-MIKEY speakers won't understand the attribute in either case? > From a MIKEY point of view, I do not care if it is general or not. However, as other people have expressed interest in using an attribute like this, I think it might be good to have something that is generic enough so you don't have to specify a new attribute if you like to replace MIKEY with something else. As I pointed out before, the approach we are using seems to be equal to the "fmtp" approach where SDP does not need to understand the content and where it is not necessary to create a new attribute each time you like to change/replace another key mgmt protocol. Fredrik > > > Colin > > > > > > --> "Fredrik Lindholm (ERA)" writes: > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@isi.edu] > >> > >> --> "Fredrik Lindholm" writes: > > > >> > > >> >To conclude our own thoughts, we believe that it is better > >> from a modularity > >> >perspective to actually use the "blob" approach, as it > will give the > >> >smallest impact on both the key management protocol and SDP. > >> > >> I'm not sure I agree, although you make a number of good > >> points. How does > >> the "blob" compare to an approach in the style of "a=fmtp" > >> though? Generic > >> SDP attribute, with each key management protocol defining > >> parameters to be > >> used within it? Fits the SDP model better, allows the key > >> management to use > >> the SDP parser to find its parameters, yet doesn't limit the > >> protocol to a > >> single key management scheme. > >> > > > >Using the SDP parser is not something I would recommend. > >First of all, the key management protocols (almost all) > >have already a built in parser (so it is there, and > >something similar must still be in place to verify that > >the attributes are of valid types etc.). Secondly, the > >protocol is generally defined in a way that the MAC/ > >Signature, protecting the data that are sent, are > >computed over the entire key management message (which > >is built up by a set of pre-defined payloads). > > > >If you then would like to split the key management message > >into sub parts and provide these as some values in SDP, the > >key management protocol still have to create the set of > >payloads and compute the MAC, before it can be split into > >subparts. When an SDP message arrives, the SDP parser must > >first parse the set of attributes, send it to the key > >management, which then must merge these together into > >payloads in order to be able to verify the MAC/Signature. > >This is not very good from a security point of view, as > >you would like to verify the MAC/Signature as soon as > >possible. I think this approach would create too much double > >work unless the parameter is more or less a "blob". > > > >I think the approach we have chosen are very equal to the > >"fmtp", or? The only description of fmtp that I found said: > >"This attribute allows parameters that are specific to a > >particular format to be conveyed in a way that SDP doesn't > >have to understand them.". As I see it, we have almost the > >exact same approach, except that we have it spread out on > >three different lines. > > > >a=fmtp: > > > >To compare: > > > >a=keymgmt-prot: // this is equal to > >a=keymgmt-data: // this is equal to the format specific data > >a=keymgmt-auth: // this is equal/subpart to/of the > format specific data > > > >So we could of course think of merging these into one line > >and define: > >a=keymgmt: > > > >and using a similar description to fmtp: > > > >This attribute allows parameters that are specific to a > >particular key management protocol to be conveyed in a way > >that SDP doesn't have to understand them. Key management > >specific parameters may be any set of parameters required > >to be conveyed by SDP and given unchanged to the key > >management protocol that will use this format. > > > >If we use this approach, I'll guess we don't have to worry > >that much about the "blob" thing, as each key management > >protocol in practice can choose either way that is > >appropriate. > > > >Fredrik > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 4 11:57:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22593 for ; Thu, 4 Apr 2002 11:57:45 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14451; Thu, 4 Apr 2002 11:53:10 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14416 for ; Thu, 4 Apr 2002 11:53:08 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22406 for ; Thu, 4 Apr 2002 11:53:04 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g34Gr73G002365 for ; Thu, 4 Apr 2002 18:53:07 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 04 18:26:39 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Apr 2002 18:16:24 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4142@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Thu, 4 Apr 2002 18:25:55 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org If you get a deja vu experience reading this mail, it is probably because I tried to send it once before (but as I interpreted it, it did not reach its destination). > > I think we need to step back, and evaluate what we're trying > to solve here. > If the key management attributes are to be general purpose, > and can be used > with a range of key exchange protocols, then I would argue > that they should > be visible to SDP and have well defined semantics at the SDP > level. In this > case, I'd expect to see something like: > > a=key-mgnt:mikey algorithm=aes key=... mac=... > > for an appropriate set of generic key-exchange/authentication > parameters. > In this case, I'd expect another keying protocol to use > mostly the same > parameters, and to pick them up from the SDP. Using almost the same reasons, I would argue the opposite, as it is very hard to find a set of good attributes that can be used with a variety of protocols (as the key mgmt protocols have very different properties). It is also not clear how these attributes could be used in the key mgmt response, as it might (in one extreme) be a message where everything are encrypted. > > If, however, they're opaque and used solely by a particular > protocol, then > I don't see the advantage of trying to make the attribute > generic. Why use > a=keymgmt-prot:MIKEY > a=keymgmt-data: > instead of > a=mikey: > when non-MIKEY speakers won't understand the attribute in either case? > From a MIKEY point of view, I do not care if it is general or not. However, as other people have expressed interest in using an attribute like this, I think it might be good to have something that is generic enough so you don't have to specify a new attribute if you like to replace MIKEY with something else. As I pointed out before, the approach we are using seems to be equal to the "fmtp" approach where SDP does not need to understand the content and where it is not necessary to create a new attribute each time you like to change/replace another key mgmt protocol. Fredrik > > > Colin > > > > > > --> "Fredrik Lindholm (ERA)" writes: > >> -----Original Message----- > >> From: Colin Perkins [mailto:csp@isi.edu] > >> > >> --> "Fredrik Lindholm" writes: > > > >> > > >> >To conclude our own thoughts, we believe that it is better > >> from a modularity > >> >perspective to actually use the "blob" approach, as it > will give the > >> >smallest impact on both the key management protocol and SDP. > >> > >> I'm not sure I agree, although you make a number of good > >> points. How does > >> the "blob" compare to an approach in the style of "a=fmtp" > >> though? Generic > >> SDP attribute, with each key management protocol defining > >> parameters to be > >> used within it? Fits the SDP model better, allows the key > >> management to use > >> the SDP parser to find its parameters, yet doesn't limit the > >> protocol to a > >> single key management scheme. > >> > > > >Using the SDP parser is not something I would recommend. > >First of all, the key management protocols (almost all) > >have already a built in parser (so it is there, and > >something similar must still be in place to verify that > >the attributes are of valid types etc.). Secondly, the > >protocol is generally defined in a way that the MAC/ > >Signature, protecting the data that are sent, are > >computed over the entire key management message (which > >is built up by a set of pre-defined payloads). > > > >If you then would like to split the key management message > >into sub parts and provide these as some values in SDP, the > >key management protocol still have to create the set of > >payloads and compute the MAC, before it can be split into > >subparts. When an SDP message arrives, the SDP parser must > >first parse the set of attributes, send it to the key > >management, which then must merge these together into > >payloads in order to be able to verify the MAC/Signature. > >This is not very good from a security point of view, as > >you would like to verify the MAC/Signature as soon as > >possible. I think this approach would create too much double > >work unless the parameter is more or less a "blob". > > > >I think the approach we have chosen are very equal to the > >"fmtp", or? The only description of fmtp that I found said: > >"This attribute allows parameters that are specific to a > >particular format to be conveyed in a way that SDP doesn't > >have to understand them.". As I see it, we have almost the > >exact same approach, except that we have it spread out on > >three different lines. > > > >a=fmtp: > > > >To compare: > > > >a=keymgmt-prot: // this is equal to > >a=keymgmt-data: // this is equal to the format specific data > >a=keymgmt-auth: // this is equal/subpart to/of the > format specific data > > > >So we could of course think of merging these into one line > >and define: > >a=keymgmt: > > > >and using a similar description to fmtp: > > > >This attribute allows parameters that are specific to a > >particular key management protocol to be conveyed in a way > >that SDP doesn't have to understand them. Key management > >specific parameters may be any set of parameters required > >to be conveyed by SDP and given unchanged to the key > >management protocol that will use this format. > > > >If we use this approach, I'll guess we don't have to worry > >that much about the "blob" thing, as each key management > >protocol in practice can choose either way that is > >appropriate. > > > >Fredrik > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 4 12:26:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24324 for ; Thu, 4 Apr 2002 12:26:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17860; Thu, 4 Apr 2002 12:24:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17831 for ; Thu, 4 Apr 2002 12:24:28 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24242 for ; Thu, 4 Apr 2002 12:24:24 -0500 (EST) Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g34HN8Cl005321; Thu, 4 Apr 2002 09:23:08 -0800 (PST) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABI92825; Thu, 4 Apr 2002 09:21:21 -0800 (PST) Message-Id: <4.3.2.7.2.20020404092006.06dd5968@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 04 Apr 2002 09:22:05 -0800 To: Stephen Casner From: Mark Baugher Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion Cc: In-Reply-To: <20020403201958.A48839-100000@ash.packetdesign.com> References: <200204032346.g33NkC19000756@purple.nge.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Steve At 08:21 PM 4/3/2002 -0800, Stephen Casner wrote: >On Wed, 3 Apr 2002, Colin Perkins wrote: > > > If, however, they're opaque and used solely by a particular protocol, then > > I don't see the advantage of trying to make the attribute generic. Why use > > a=keymgmt-prot:MIKEY > > a=keymgmt-data: > > instead of > > a=mikey: > > when non-MIKEY speakers won't understand the attribute in either case? > >Well, it seems a bit dangerous to insert the namespace of key >management protocols into the SDP attribute namespace. I'm not certain which alternative, if either, you are arguing for or against. Frankly, the nuance of difference between the two alternatives escapes me. Mark > -- 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 mmusic-admin@ietf.org Thu Apr 4 21:35:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15370 for ; Thu, 4 Apr 2002 21:35:44 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19772; Thu, 4 Apr 2002 21:31:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA19738 for ; Thu, 4 Apr 2002 21:31:47 -0500 (EST) Received: from goobox (tog-wakko3.prognet.com [207.188.29.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15339 for ; Thu, 4 Apr 2002 21:31:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 04 Apr 2002 18:31:33 -0800 >Return-Path: Received: from mail.real.com [207.188.7.41] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Thu, 04 Apr 2002 18:31:33 -0800 (PST) Received: from usw-sf-list1.sourceforge.net (usw-sf-fw2.sourceforge.net [216.136.171.252]) by real.com (8.12.2/8.12.2) with ESMTP id g352S0xt003925 for ; Thu, 4 Apr 2002 18:28:01 -0800 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16tJSM-0004GJ-00 for ; Thu, 04 Apr 2002 18:28:02 -0800 From: rtspspec-bugs-request@lists.sourceforge.net X-Mailer: Mailman v2.0.5 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.5 Precedence: bulk Message-Id: Date: Thu, 04 Apr 2002 18:28:02 -0800 X-Spam-Status: No, hits=0.6 required=5.5 tests=NO_REAL_NAME version=2.20 X-UIDL: d7e880560710be8aaf5e64f786ade09d To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #32 - 4 msgs Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org 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-538997 ] Need to flesh out 1.5 (Extending RTSP) (noreply@sourceforge.net) 2. [ rtspspec-Bugs-539001 ] Transport header should override m= (noreply@sourceforge.net) 3. [ rtspspec-Bugs-477427 ] Transport model requirements (noreply@sourceforge.net) 4. [ rtspspec-Bugs-539040 ] Conference header underspecified (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 03 Apr 2002 15:26:18 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-538997 ] Need to flesh out 1.5 (Extending RTSP) Bugs item #538997, was opened at 2002-04-03 15:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=538997&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Nobody/Anonymous (nobody) Summary: Need to flesh out 1.5 (Extending RTSP) Initial Comment: We need to have a larger "Extending RTSP" section in the draft: A first (very rough) cut at this was posted here: http://www.ietf.org/mail-archive/working-groups/mmusic/current/msg00377.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=538997&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 03 Apr 2002 15:32:06 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-539001 ] Transport header should override m= Bugs item #539001, was opened at 2002-04-03 15:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Transport header should override m= Initial Comment: Section C.1.7 ("Connection Information") states the following: "for on-demand unicast streams and some multicast streams, the destination is specified by the client via the SETUP request". The rest of this section mainly refers to the "c=" line in SDP, but it's not clear that the SETUP Transport header also overrides the port given in the m= line. Clarification of this is needed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=539001&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 03 Apr 2002 16:03:34 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477427 ] Transport model requirements Bugs item #477427, was opened at 2001-11-01 23:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194 Category: None Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Transport model requirements Initial Comment: Which connection models are required. Is non persitent TCP connections a MUST support, or only RECOMMENDED? ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-04-03 16:03 Message: Logged In: YES user_id=3796 Current section 1.1 has text which is counter to our resolution: "There is no notion of an RTSP connection...." ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-03-17 20:06 Message: Logged In: YES user_id=3796 Discussed in RTSP telecon Jan 23 (http://rtsp.org/2002/telecon/minutes23Jan.html#line90) RESOLVED: define header and response for non-persistent connections. Default is connection-oriented, and connectionless MAY be implemented. Look into "supported" header. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:07 Message: Logged In: YES user_id=3796 Good question. This is related to #492546 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477427&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 03 Apr 2002 17:16:58 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-539040 ] Conference header underspecified Bugs item #539040, was opened at 2002-04-03 17:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=539040&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Conference header underspecified Initial Comment: The "Conference" header specified in section 12.10 of the 2326bis00 is underspecified, and not implemented by known implementations. Proposal: Remove section 12.10 and section 3.3 (Conference Identifiers). MMUSIC discussion: http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00416.html ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=539040&group_id=23194 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 5 06:38:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01957 for ; Fri, 5 Apr 2002 06:38:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24686; Fri, 5 Apr 2002 06:37:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA24656 for ; Fri, 5 Apr 2002 06:36:58 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01954 for ; Fri, 5 Apr 2002 06:36:54 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g35Baq3G011908 for ; Fri, 5 Apr 2002 13:36:52 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA15900; Fri, 5 Apr 2002 13:36:52 +0200 Message-ID: <3CAD8C54.6020505@era.ericsson.se> Date: Fri, 05 Apr 2002 13:36:52 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: multipart/mixed; boundary="------------040702070702000308090203" Subject: [MMUSIC] RTSP state machine verison 0.5 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------040702070702000308090203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Here comes the latest version of the state machine for RTSP. Changes done to this version is: - Updated according to the resolutions reached during last telecon regarding setup and teardown while playing and recording, setting of resume point. - Merged the aggregated and non-aggregated versions of record, play and ready state. Question: Should we use 501 or 455 as error code when a server not implementing setup and teardown during playing and recording? Please review and say what you think about this version. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se --------------040702070702000308090203 Content-Type: text/plain; name="state-machine_v0.5.txt" Content-Disposition: inline; filename="state-machine_v0.5.txt" Content-Transfer-Encoding: 7bit RTSP state machine ver. 0.5 Changes since 0.4 ----------------- - Added resolution of issue 1-3 - Merged the aggregated and non aggregated versions. This requires that the state variable nr-medias is checked. For nr-medias equal to one certain behavior is used. For cases where nr-medias is two or more other operations will happend. To avoid creating to many variants in the tables a important definition has been made regarding presentation urls. In non aggregated control the presentation URL is equal to the media URL. In aggregated control the presenttion URL is seperated from the media URLs. See note below. It is based on the proposal that in aggregated control, PAUSE and PLAY can't be used on individual medias. If that is allowed there will be a number of extra transitions with requirements on the different medias state. It also using the assumption that queued play is removed. There is discussion if teardown on media URL should end up in a middle state between Init and Ready-na. This state would contain no media but keep all session related state and keep its ID. The only way to remove such a state will be the teardown with * or a session timeout. It has been added in this version with the state name "Ready-nm". This state machine has removed the automatic state transtitions relative to end of media or range. The automatic state transition that remain is session tiemout and when reaching a specifed pause point. Missing in state table ---------------------- Of course it is missing things but please help me find what! Issues ------ 4. Should we have the READY-nm state that this version shows? 5. When doing setup for recording is there a requirement to have done announce before? 6. Should REDIRECT without range or reaching the readirect point result in imediatly closeing of the session? This is suggested by the old client state machine that send the client to Init on redirect. The text in chapter 10.10 says that the client should issue a teardown of previous session. States Explanation ----------------------------------------------------------------------- Init Initial state no session exist Ready-nm Ready state without any medias Ready Session is ready to start playing or recording Play Session is playing Record Session is recording State variables --------------- Nr-media The number of medias currently setuped in this session RP = Resume point The point that a play request without range resumes. Abrivations ----------- PP Pause Point RP Resume point Prs Presentation IFI IF Implemented RedP Redirect Point #md Nr-media Note: In the case that #md = 1 the presentation URL is equal to the media URL. For #md > 1 the presentation URL MUST be other than any of the medias that are part of the session. This applies to all states. None state machine changeing events Action Prerequisite Response ----------------------------------------------------------------------- DESCRIBE Needs REDIRECT 3xx Redirect DESCRIBE 200, Session description OPTIONS Session ID 200, Reset sess timeout timer OPTIONS 200, Allow hdr SET_PARAMETER Valid parameter 200, change value of parameter GET_PARAMETER Valid parameter 200, return value of parameter ANNOUNCE C->S, support rec. ANNOUNCE S->C, update session State: Init Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP Ready #md = 1, RP=0.0 SETUP URL->Redirect Init 3xx Redirect State: Ready-nm Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP Ready #md = 1, RP=0.0 TEARDOWN * Init No session hdr. Timeout Init State: Ready Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready #md +=1 SETUP Setuped URL Ready Change transport param. TEARDOWN * Init No session hdr TEARDOWN Prs URL,#md>1 Init No session hdr TEARDOWN md URL,#md=1 Ready-nm Session hdr, #md = 0 TEARDOWN md URL,#md>1 Ready Session hdr, #md -= 1 PLAY Prs URL | No range Play Play from RP | Range Play according to range RECORD Record Timeout Init State: Play Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE PrsURL,No range Ready Set RP to present point PAUSE PrsURL,Range>now Play Set RP & PP to given point PAUSE PrsURL,Range<=now Ready Set RP to present pos. PP reached Ready RP = PP End of media All media Play No action, RP = Invalid End of media >=1 Media plays Play No action End of range Play Set RP = End of range SETUP New URL,IFI Play #md+=1, 200, RTP-Info SETUP New URL PLAY 455 alt 501 SETUP Setuped URL Play Change transport param. TEARDOWN URL=* Init No session hdr TEARDOWN Prs URL,#md>1 Init No session hdr TEARDOWN md URL,#md=1,IFI Ready-nm Session hdr TEARDOWN md URL,#md>1,IFI Play Session hdr TEARDOWN md URL PLAY 455 alt 501 S->C:REDIRECT Range hdr Play S->C:REDIRECT no range hdr Play Stop Media Playout RedP reached Play Stop Media playout Timeout Init State: Record Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE Ready Out-of-disk Ready TEARDOWN URL=* Init No session hdr TEARDOWN Prs URL,#md>1 Init No session hdr TEARDOWN md URL,#md=1,IFI Ready-nm Session hdr TEARDOWN md URL,#md>1,IFI Record Session hdr TEARDOWN md URL Record 455 alt 501 S->C:REDIRECT Range hdr Record Set Redirect Point S->C:REDIRECT w/o range hdr Record Stop Recording RedP reached Record Stop Recording Timeout Init --------------040702070702000308090203-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 5 10:45:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07864 for ; Fri, 5 Apr 2002 10:45:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08236; Fri, 5 Apr 2002 10:36:07 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA08197 for ; Fri, 5 Apr 2002 10:36:04 -0500 (EST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07631 for ; Fri, 5 Apr 2002 10:35:58 -0500 (EST) From: suresh.leroy@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g35FZSL21412 for ; Fri, 5 Apr 2002 17:35:28 +0200 (MET DST) Received: from alcatel.be ([138.203.33.40]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002040517352505:840 ; Fri, 5 Apr 2002 17:35:25 +0200 Message-ID: <3CADC43C.8693B411@alcatel.be> Date: Fri, 05 Apr 2002 17:35:24 +0200 Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/05/2002 17:35:25, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/05/2002 17:35:27, Serialize complete at 04/05/2002 17:35:27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDP(ng)&QoS Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hey all, During the last IETF meeting there was a presentation given by Joerg Ott on QoS extensions for the session description protocol. The intention from the chair was to see if there is interest for the MMUSIC wg to work on this topic, unfortunately there was no time for discussion so lets try to do this via e-mail. Below I tried to answer most of the questions mentioned at the end of the 'SDP(ng) & QoS' as we really believe these type of extensions are needed. But before starting, when looking at the draft-ietf-mmusic-sdpng-req-01.txt there is a explicit requirement for QoS extensions in chapter "QoS-Parameters for different protocol domains (e.g. traffic specification and flow specification or TOS bits for IP QoS) need to be specified.". So it seems in the past this type of discussion already took place and was agreed. WHAT HAVE WE MISSED SO FAR? If we look at what is currently being defined in SIP and SDP related to QoS there are mainly two things: 1) The manyfolks draft allows to request the need for QoS provisioning and the indication of success of reservation. 2) The media authorisation token allows the authorisation of the QoS for the different media streams by providing a binding between the media stream in the SDP and the QoS siganlling for the media streams. What is still missing is the QoS information itself, which cannot always be derived from media description in SDP! The QoS information in the session description will be a valuable source of information to base the actual QoS reservation on (e.g. RVSP, NSIS protocol, ...). Potential uses of the QoS extensions: 1. Synchronisation of the QoS in the different domains. Quality of service will most probably be handled differently depending on the type of access networks and backbone network. 2. Allows differentiation between the sessions (e.g. business vs private sessions) and between type of subscribers (e.g. premium vs basic subscription). 3. Allows end-users to negotiate in a flexible way the QoS they want for each medium in the session prior to the QoS provisioning itself. 4. Facilitates the introduction of new codecs. 5. Allows to specify E2E QoS for media streams that are not associated with a codec. 6. Input for the QoS provisioning protocols like e.g. RSVP or NSIS. 7. Service provider are more than just bit pipe providers (extra revenues). 8. Service level admission control in the local access network and home service provider. DO WE NEED QOS INFORMATION BEYOND WHAT CAN BE DERIVED FROM THE CURRENT SDP? The only thing from which we can derive QoS information in the current session description protocols is the codec itself (or the optional b= parameter). Here is already the first problem. Not all media are associated with a codec! E.g. whiteboard applications. Not all the involved parties might be aware of the QoS needed for new codecs (e.g. fancy downloadable applications) From the codec itself it is possible to derive traffic parameters like e.g. peak-bandwidth, sustainable bandwidth, packet size, ... as normally one codec only corresponds with one traffic information set. The parameters that define the level of perception by the end-users cannot as such by derived from the codec. These 'QoS' parameters are delay, delay variation, & packet loss ratio. The set of QoS parameters (called 'SI' sensitivity information in draft-bos-mmusic-sdpng-qos-00.txt) allow the end-user and/or service providers to differentiate among the sessions and each other. Explicitly specifying the traffic information allows proper authorisation of the media stream by the service providers without having to know the codec itself. WHERE WOULD THIS INFORMATION COME FROM? First of all this information should be optional, it must be possible to setup session without having to add QoS information to the session description. The QoS extensions can be added to the session description by either the end-user or the service provider. The most obvious scenario is when the end user specifies the QoS level. In case of roaming users both the local access provider and the home service provider should be able to check/modify the QoS. Another scenario could be were the end-user doesn't specify anything but for instance the service provider checks in the subscription profile what level of QoS the end-user is allowed to use and adds this to the session description. If we look at draft-bos-mmusic-sdpng-qos-00.txt there are three different ways to specify the Sensitivity information (e.g. delay, jitter and packet loss ratio). The first one is the complete parameter set, which implies you specify a value for every parameter. These values are an indication of the upper bound for the parameters. The second option is the use of standardised QoS classes. The QoS classes need to be standardised by a recognised standardisation body like IETF, ITU, ... so that they can be understood by all the parties involved. The last option mentioned in the draft is the use of QoS flavours. The QoS flavour is just like QoS classes an abbreviated representation form of the Sensitivity Information. The difference with QoS classes is that they are defined by the service provider and as such only interpretable by the end-user and his service provider. Based on the destination (other service provider) the service provider can translate the QoS flavour to either the parameter or the QoS class representation form. IS THERE A NEED TO SIGNAL THIS INBAND? Adding QoS information to the session description is a logical choice. First of all it is in the session description that the QoS information can be linked to the specific media streams. If for instance the local access provider cannot offer you bandwidths higher than 20 kbps this will affect the choice of codec. Also per media stream more than one QoS level could be suggested and together with the codec negotiation the QoS negotiation takes place. The QoS information can be linked to the QoS pre-conditions (manyfolks). By signalling the QoS inband all the involved parties (e.g. local access provider, service provider & end-hosts) are aware/involved in the QoS negotiation. Mechanisms at the session layer (e.g. SIP) as record-route, offer-answer model, firewall traversal, etc are automatically supported. The QoS extensions are not used for QoS provisioning. Regards, Suresh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 5 12:51:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11457 for ; Fri, 5 Apr 2002 12:51:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17173; Fri, 5 Apr 2002 12:45:13 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17143 for ; Fri, 5 Apr 2002 12:45:11 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11339 for ; Fri, 5 Apr 2002 12:45:06 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g35HisU17451; Fri, 5 Apr 2002 12:44:54 -0500 Message-Id: <200204051744.g35HisU17451@chiron.nge.isi.edu> To: "Dan Firac" cc: mmusic@ietf.org Subject: Re: [MMUSIC] Silence Suppression Attribute In-Reply-To: Your message of "Thu, 04 Apr 2002 10:37:03 +0300." <004701c1dbab$83e50740$1b00a8c0@softtel.ro> Date: Fri, 05 Apr 2002 12:44:54 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Dan, I think Steve's email mostly answers this. If the codec has parameters to determine how the silence suppression works, these need to be specified as part of the payload format. For just signalling the preference that that suppression not be performed (and clearly this can only be a preference), a "generic format parameters" is probably the best way to proceed, rather than a specific attribute for silence suppression. Colin --> "Dan Firac" writes: >It's about user preferences. > >Scenario: >If the user prefers to DISABLE Silence Suppresion in order to acheive higher >audio quality, then the SDP composed by its phone should express this wish. > >Further pros: >1) Silence suppression it's a PARAMETER for many codecs, and >I think it should be present in SDP offers/answers. >2) When the remote end is not well tuned (ex: volumes), the VAD on the >remote end may >brutally cut the speech, so our local user will not know/feel if there were >loses or >the remote user stopped speaking. >3) The same thing happens when the local user has G723 without AnnexA (VAD), >G729 without AnnexB, and would want to force the remote end to use >a codec without silence suppression. > >Points 2) and 3) are about gaining some quality. > >You are right, RTP assumes silence suppression and all the scenarios >(including the above scenarios) are working without negotiating Silence >Suppression. >But is the obtained quality the best quality that can be acheived????? > >I think the user should decide it and the SDP should offer him >a mechanism (at least, optional) to express his preferences. > >Best regards, >Dan Firac, >Software Engineer, >RedlineCommunications, >Romania. > > >----- Original Message ----- >From: "Colin Perkins" >To: "Dan Firac" >Cc: "Tom-PT Taylor" ; >Sent: Thursday, April 04, 2002 2:22 AM >Subject: Re: [MMUSIC] Silence Suppression Attribute > > >> What would be the scenario where the new attribute is used? >> Colin >> >> >> --> "Dan Firac" writes: >> >It's a very good ideea. >> >Anyway, why this attribute was defined for ATM transport type only? >> >Silence suppression, as you pointed below, is an attribute of a codec >> >and has nothing to do with transport. >> > >> >Dan Firac, >> >Software Engineer, >> >RedlineCommunications, >> >Romania. >> > >> > >> > >> > >> >----- Original Message ----- >> >From: "Tom-PT Taylor" >> >To: ; >> >Sent: Wednesday, April 03, 2002 12:10 AM >> >Subject: [MMUSIC] Silence Suppression Attribute >> > >> > >> >> The issue of how to signal silence suppression capability keeps coming >up >> >on >> >> the Megaco list. The situation is fairly complicated: >> >> - some codecs come with a pre-defined capability for silence >suppression. >> >> This capability can be invoked by the appropriate MIME type parameter >as >> >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to >RTP >> >> transport, arguably over UDP only. >> >> - other codecs like G.711 have no such parameter, yet silence >suppression >> >> is possible >> >> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM >> >> transport only. >> >> >> >> How would people feel about allowing the a=silenceSupp parameter to be >> >used >> >> independently of the transport type? >> >> >> >> Tom Taylor >> >> taylor@nortelnetworks.com >> >> Ph. +1 613 736 0961 (ESN 396 1490) >> >> >> >> >> >> _______________________________________________ >> >> 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 mmusic-admin@ietf.org Fri Apr 5 16:33:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19382 for ; Fri, 5 Apr 2002 16:33:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29939; Fri, 5 Apr 2002 16:30:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29906 for ; Fri, 5 Apr 2002 16:30:26 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19301 for ; Fri, 5 Apr 2002 16:30:21 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g35LULu18389; Fri, 5 Apr 2002 16:30:21 -0500 Message-Id: <200204052130.g35LULu18389@chiron.nge.isi.edu> To: Stephen Casner cc: "Fredrik Lindholm (ERA)" , mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Wed, 03 Apr 2002 20:21:24 PST." <20020403201958.A48839-100000@ash.packetdesign.com> Date: Fri, 05 Apr 2002 16:30:21 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> Stephen Casner writes: >On Wed, 3 Apr 2002, Colin Perkins wrote: > >> If, however, they're opaque and used solely by a particular protocol, then >> I don't see the advantage of trying to make the attribute generic. Why use >> a=keymgmt-prot:MIKEY >> a=keymgmt-data: >> instead of >> a=mikey: >> when non-MIKEY speakers won't understand the attribute in either case? > >Well, it seems a bit dangerous to insert the namespace of key >management protocols into the SDP attribute namespace. Only if there are likely to be many key management protocols used. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 5 16:35:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19453 for ; Fri, 5 Apr 2002 16:35:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29723; Fri, 5 Apr 2002 16:29:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29688 for ; Fri, 5 Apr 2002 16:29:51 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19259 for ; Fri, 5 Apr 2002 16:29:46 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g35LTmx18375; Fri, 5 Apr 2002 16:29:48 -0500 Message-Id: <200204052129.g35LTmx18375@chiron.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Thu, 04 Apr 2002 10:15:15 +0200." <0DAEDF148988D411BB980008C7E65D2E04FE413B@esealnt416> Date: Fri, 05 Apr 2002 16:29:48 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Fredrik Lindholm (ERA)" writes: > >> >> I think we need to step back, and evaluate what we're trying >> to solve here. >> If the key management attributes are to be general purpose, >> and can be used >> with a range of key exchange protocols, then I would argue >> that they should >> be visible to SDP and have well defined semantics at the SDP >> level. In this >> case, I'd expect to see something like: >> >> a=key-mgnt:mikey algorithm=aes key=... mac=... >> >> for an appropriate set of generic key-exchange/authentication >> parameters. >> In this case, I'd expect another keying protocol to use >> mostly the same >> parameters, and to pick them up from the SDP. > >Using almost the same reasons, I would argue the opposite, >as it is very hard to find a set of good attributes that can >be used with a variety of protocols (as the key mgmt protocols >have very different properties). It is also not clear how these >attributes could be used in the key mgmt response, as it might >(in one extreme) be a message where everything are encrypted. This is exactly why I don't like the idea of generic key management attributes. If there are no common parameters, why try to merge the signalling? >> If, however, they're opaque and used solely by a particular >> protocol, then >> I don't see the advantage of trying to make the attribute >> generic. Why use >> a=keymgmt-prot:MIKEY >> a=keymgmt-data: >> instead of >> a=mikey: >> when non-MIKEY speakers won't understand the attribute in either case? >> > >>From a MIKEY point of view, I do not care if it is general or >not. However, as other people have expressed interest in >using an attribute like this, I think it might be good to have >something that is generic enough so you don't have to specify >a new attribute if you like to replace MIKEY with something else. >As I pointed out before, the approach we are using seems to be >equal to the "fmtp" approach where SDP does not need to >understand the content and where it is not necessary to create >a new attribute each time you like to change/replace another >key mgmt protocol. For each key exchange protocol, you need to map it onto the offer - answer model (or other SDP usage scenario), define the syntax of the keying information, and register the name of the keying protocol. With "a=keymgmt-prot:" you have defined a new IANA registry of key exchange protocol names, and for each protocol you need to register an entry there and define how it is used. With an SDP attribute for each key exchange protocol, the only difference is that the name is registered in the SDP attribute namespace. The same parameters need to be defined. I don't see how the generic attributes make this process easier? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 5 18:53:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10698 for ; Fri, 5 Apr 2002 18:53:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07205; Fri, 5 Apr 2002 18:52:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07178 for ; Fri, 5 Apr 2002 18:52:34 -0500 (EST) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10514 for ; Fri, 5 Apr 2002 18:52:29 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g35NqKV19028; Fri, 5 Apr 2002 18:52:20 -0500 Message-Id: <200204052352.g35NqKV19028@chiron.nge.isi.edu> To: "David Yon" cc: mmusic@ietf.org Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Tue, 02 Apr 2002 14:16:24 EST." Date: Fri, 05 Apr 2002 18:52:20 -0500 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: > >http://www.dialout.net/public/ietf/draft-ietf-mmusic-sdp-comedia-02.txt > >The above link is an unofficial copy that I've posted for discussion >purposes. The following changes have been made since comedia-01: > > - The assumption now is that media only ever needs a single > connection, which simplifies the semantics of >"direction:both". > > - A method to reduce the probability that "direction:both" > will result in an extra connection is discussed (section 2.4). > > - Rohan Mahy's text about UDP and RTP/AVP is incorporated > (sections 2.6 and 5.4). > > - "direction:reuse" has been removed. Section 4.3 covers > the scenarios that reuse intended to address. > > - A discussion of listener and connection lifetime has been > added (section 4). > > - The BNF has been checked for compatibility with SDPnew. > >I've gone through and made sure that comedia meets the SDP requirements >discussed in Jeorg's slides in Minneapolis (session setup, session >pause, session resume, session redirect, session parameter renegotiate, >session teardown). At this point I don't see anything missing. >Pause/resume/redirect/renegotiate are directly addressed in section 4. > >Modulo any showstopper issues brought up in the list, I'm ready to >submit this as the official comedia-02 at any time. > >Everyone is encouraged to review and provide feedback as soon as >possible. We'd like to get this into Last Call in the next week or two. This looks pretty good. A few comments: - The Protocol Identifiers section may want to point to the discussion of m= in SDP, which specifies that the identifiers are MIME subtypes for audio/video/application media types. This is implicit in the examples, and explicit in SDP, but not noted in this draft. - Section 2.2 ("Semantics of direction:active") could go with an SDP fragment, showing exactly where the source and destination address and port are specified (i.e. an SDP fragment including c=, m= and a=direction lines). - How specific is this to SDP used with offer/answer? It's probably appropriate to have a section explaining how comedia is used with SIP (i.e. offer/answer), RTSP, MEGACO and perhaps SAP. - Section 2.6 says that you MUST NOT send media on a passive port until a packet has been received. Does this include not sending RTCP? - In section 3, how is the source address useful given that it can't be trusted? More explanation of how it can be used is probably needed. - Section 4.1: the time window is the t= line? - The possible race when both parties select diraction:both concerns me, but I'm not sure I can see a better alternative (unless there's some trick to make one side win deterministically, for example the lowest IP address wins). Editorial comments: - The section numbering needs to start with the introduction as section 1. - The introduction and motivation sections could easily be combined. Add a couple of sentances to the end of the combined section saying that "this memo defines two new protocol identifies, TCP and TLS, along with the syntax and semantics of the a=direction attribute". - Move the terminology section after the combined introduction/motivation - A couple of instances of non-ASCII characters need to be fixed. - A couple of places say "the a= line" but mean "the a=direction:" line (e.g. end of section 2.2, second paragraph of section 2.3, ...) Regards, Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 01:09:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07359 for ; Mon, 8 Apr 2002 01:09:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29507; Mon, 8 Apr 2002 01:06:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29435 for ; Mon, 8 Apr 2002 01:06:38 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07294; Mon, 8 Apr 2002 01:06:36 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3855rCl019256; Sun, 7 Apr 2002 22:05:53 -0700 (PDT) Received: from RKUMARW2K (sjc-vpn3-537.cisco.com [10.21.66.25]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id WAA14688; Sun, 7 Apr 2002 22:06:00 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Colin Perkins" , "Dan Firac" Cc: , Subject: RE: [MMUSIC] Silence Suppression Attribute Date: Sun, 7 Apr 2002 22:06:00 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200204051744.g35HisU17451@chiron.nge.isi.edu> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Please comment on http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt . This might fit the "generic format parameters" Colin mentioned. Rajesh Kumar Cisco Systems > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Colin Perkins > Sent: Friday, April 05, 2002 9:45 AM > To: Dan Firac > Cc: mmusic@ietf.org > Subject: Re: [MMUSIC] Silence Suppression Attribute > > > Dan, > > I think Steve's email mostly answers this. If the codec has parameters to > determine how the silence suppression works, these need to be specified as > part of the payload format. > > For just signalling the preference that that suppression not be performed > (and clearly this can only be a preference), a "generic format parameters" > is probably the best way to proceed, rather than a specific attribute for > silence suppression. > > Colin > > > --> "Dan Firac" writes: > >It's about user preferences. > > > >Scenario: > >If the user prefers to DISABLE Silence Suppresion in order to > acheive higher > >audio quality, then the SDP composed by its phone should express > this wish. > > > >Further pros: > >1) Silence suppression it's a PARAMETER for many codecs, and > >I think it should be present in SDP offers/answers. > >2) When the remote end is not well tuned (ex: volumes), the VAD on the > >remote end may > >brutally cut the speech, so our local user will not know/feel if > there were > >loses or > >the remote user stopped speaking. > >3) The same thing happens when the local user has G723 without > AnnexA (VAD), > >G729 without AnnexB, and would want to force the remote end to use > >a codec without silence suppression. > > > >Points 2) and 3) are about gaining some quality. > > > >You are right, RTP assumes silence suppression and all the scenarios > >(including the above scenarios) are working without negotiating Silence > >Suppression. > >But is the obtained quality the best quality that can be acheived????? > > > >I think the user should decide it and the SDP should offer him > >a mechanism (at least, optional) to express his preferences. > > > >Best regards, > >Dan Firac, > >Software Engineer, > >RedlineCommunications, > >Romania. > > > > > >----- Original Message ----- > >From: "Colin Perkins" > >To: "Dan Firac" > >Cc: "Tom-PT Taylor" ; > >Sent: Thursday, April 04, 2002 2:22 AM > >Subject: Re: [MMUSIC] Silence Suppression Attribute > > > > > >> What would be the scenario where the new attribute is used? > >> Colin > >> > >> > >> --> "Dan Firac" writes: > >> >It's a very good ideea. > >> >Anyway, why this attribute was defined for ATM transport type only? > >> >Silence suppression, as you pointed below, is an attribute of a codec > >> >and has nothing to do with transport. > >> > > >> >Dan Firac, > >> >Software Engineer, > >> >RedlineCommunications, > >> >Romania. > >> > > >> > > >> > > >> > > >> >----- Original Message ----- > >> >From: "Tom-PT Taylor" > >> >To: ; > >> >Sent: Wednesday, April 03, 2002 12:10 AM > >> >Subject: [MMUSIC] Silence Suppression Attribute > >> > > >> > > >> >> The issue of how to signal silence suppression capability > keeps coming > >up > >> >on > >> >> the Megaco list. The situation is fairly complicated: > >> >> - some codecs come with a pre-defined capability for silence > >suppression. > >> >> This capability can be invoked by the appropriate MIME type > parameter > >as > >> >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is > specific to > >RTP > >> >> transport, arguably over UDP only. > >> >> - other codecs like G.711 have no such parameter, yet silence > >suppression > >> >> is possible > >> >> - RFC 3108 defined an a=silenceSupp attribute, but it > applies to ATM > >> >> transport only. > >> >> > >> >> How would people feel about allowing the a=silenceSupp > parameter to be > >> >used > >> >> independently of the transport type? > >> >> > >> >> Tom Taylor > >> >> taylor@nortelnetworks.com > >> >> Ph. +1 613 736 0961 (ESN 396 1490) > >> >> > >> >> > >> >> _______________________________________________ > >> >> mmusic mailing list > >> >> mmusic@ietf.org > >> >> https://www1.ietf.org/mailman/listinfo/mmusic > >> > > >> > > >> >_______________________________________________ > >> >mmusic mailing list > >> >mmusic@ietf.org > >> >https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 04:05:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17416 for ; Mon, 8 Apr 2002 04:05:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17299; Mon, 8 Apr 2002 04:01:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17262 for ; Mon, 8 Apr 2002 04:01:21 -0400 (EDT) Received: from mail.redlinecommunications.ro (root@gate.redlinecommunications.ro [213.154.146.122]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17342 for ; Mon, 8 Apr 2002 04:00:51 -0400 (EDT) Received: from dan (dan.softtel.ro [192.168.0.27]) by mail.redlinecommunications.ro (8.11.4/8.11.4) with SMTP id g387xex01522; Mon, 8 Apr 2002 10:59:40 +0300 Message-ID: <005d01c1ded2$c53703e0$1b00a8c0@softtel.ro> From: "Dan Firac" To: "Colin Perkins" Cc: , References: <200204051744.g35HisU17451@chiron.nge.isi.edu> Subject: Re: [MMUSIC] Silence Suppression Attribute Date: Mon, 8 Apr 2002 10:55:37 +0300 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.2462.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Silence suppression can fit "generic format paramters". As long as nothing is standardized i would like to express my opinions about this solution. 1) It's very probable that the user would NOT set different values for the silence suppression attribute of each codec. So, this value can be transmitted only once as an attibute of media level. 2) (for rajesh) I think inserting 'ecan' in your parameter list is not a wise thing to do. Because the echo cancelation is NOT a codec parameter (you won't find the echo cancelation block as an codec integrated part, but as a separate one !!!). As far as I know the echo cancelation block operates (at receiver) AFTER the codec. So, I think 'ecan' may be moved to media level. Given the above opinions and the fact that the 'gftmp' parameter values would not differ from codec to codec, I think the 'gfmtp' can be moved to media level, and any particular parameters for a certain codec should be expressed with 'ftmp' (This is the definition o 'fmtp': format SPECIFIC parameters). Here is a little inconsistency: the above implies that 'fmtp' include 'gftmp', but these are only sugestions. Please consider all above as personal opinions, Dan Firac, Software Engineer Redline Communications, Romania. ----- Original Message ----- From: "Colin Perkins" To: "Dan Firac" Cc: Sent: Friday, April 05, 2002 8:44 PM Subject: Re: [MMUSIC] Silence Suppression Attribute > Dan, > > I think Steve's email mostly answers this. If the codec has parameters to > determine how the silence suppression works, these need to be specified as > part of the payload format. > > For just signalling the preference that that suppression not be performed > (and clearly this can only be a preference), a "generic format parameters" > is probably the best way to proceed, rather than a specific attribute for > silence suppression. > > Colin > > > --> "Dan Firac" writes: > >It's about user preferences. > > > >Scenario: > >If the user prefers to DISABLE Silence Suppresion in order to acheive higher > >audio quality, then the SDP composed by its phone should express this wish. > > > >Further pros: > >1) Silence suppression it's a PARAMETER for many codecs, and > >I think it should be present in SDP offers/answers. > >2) When the remote end is not well tuned (ex: volumes), the VAD on the > >remote end may > >brutally cut the speech, so our local user will not know/feel if there were > >loses or > >the remote user stopped speaking. > >3) The same thing happens when the local user has G723 without AnnexA (VAD), > >G729 without AnnexB, and would want to force the remote end to use > >a codec without silence suppression. > > > >Points 2) and 3) are about gaining some quality. > > > >You are right, RTP assumes silence suppression and all the scenarios > >(including the above scenarios) are working without negotiating Silence > >Suppression. > >But is the obtained quality the best quality that can be acheived????? > > > >I think the user should decide it and the SDP should offer him > >a mechanism (at least, optional) to express his preferences. > > > >Best regards, > >Dan Firac, > >Software Engineer, > >RedlineCommunications, > >Romania. > > > > > >----- Original Message ----- > >From: "Colin Perkins" > >To: "Dan Firac" > >Cc: "Tom-PT Taylor" ; > >Sent: Thursday, April 04, 2002 2:22 AM > >Subject: Re: [MMUSIC] Silence Suppression Attribute > > > > > >> What would be the scenario where the new attribute is used? > >> Colin > >> > >> > >> --> "Dan Firac" writes: > >> >It's a very good ideea. > >> >Anyway, why this attribute was defined for ATM transport type only? > >> >Silence suppression, as you pointed below, is an attribute of a codec > >> >and has nothing to do with transport. > >> > > >> >Dan Firac, > >> >Software Engineer, > >> >RedlineCommunications, > >> >Romania. > >> > > >> > > >> > > >> > > >> >----- Original Message ----- > >> >From: "Tom-PT Taylor" > >> >To: ; > >> >Sent: Wednesday, April 03, 2002 12:10 AM > >> >Subject: [MMUSIC] Silence Suppression Attribute > >> > > >> > > >> >> The issue of how to signal silence suppression capability keeps coming > >up > >> >on > >> >> the Megaco list. The situation is fairly complicated: > >> >> - some codecs come with a pre-defined capability for silence > >suppression. > >> >> This capability can be invoked by the appropriate MIME type parameter > >as > >> >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is specific to > >RTP > >> >> transport, arguably over UDP only. > >> >> - other codecs like G.711 have no such parameter, yet silence > >suppression > >> >> is possible > >> >> - RFC 3108 defined an a=silenceSupp attribute, but it applies to ATM > >> >> transport only. > >> >> > >> >> How would people feel about allowing the a=silenceSupp parameter to be > >> >used > >> >> independently of the transport type? > >> >> > >> >> Tom Taylor > >> >> taylor@nortelnetworks.com > >> >> Ph. +1 613 736 0961 (ESN 396 1490) > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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 mmusic-admin@ietf.org Mon Apr 8 10:12:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24395 for ; Mon, 8 Apr 2002 10:12:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06896; Mon, 8 Apr 2002 10:02:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06852 for ; Mon, 8 Apr 2002 10:02:15 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23889 for ; Mon, 8 Apr 2002 10:02:10 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g38E1ts7014639 for ; Mon, 8 Apr 2002 16:01:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 08 15:13:47 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTDLM9>; Mon, 8 Apr 2002 15:13:47 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE414B@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Mon, 8 Apr 2002 15:13:09 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org From: Colin Perkins [mailto:csp@isi.edu] > > --> "Fredrik Lindholm (ERA)" writes: > > > >> > >> I think we need to step back, and evaluate what we're trying > >> to solve here. > >> If the key management attributes are to be general purpose, > >> and can be used > >> with a range of key exchange protocols, then I would argue > >> that they should > >> be visible to SDP and have well defined semantics at the SDP > >> level. In this > >> case, I'd expect to see something like: > >> > >> a=key-mgnt:mikey algorithm=aes key=... mac=... > >> > >> for an appropriate set of generic key-exchange/authentication > >> parameters. > >> In this case, I'd expect another keying protocol to use > >> mostly the same > >> parameters, and to pick them up from the SDP. > > > >Using almost the same reasons, I would argue the opposite, > >as it is very hard to find a set of good attributes that can > >be used with a variety of protocols (as the key mgmt protocols > >have very different properties). It is also not clear how these > >attributes could be used in the key mgmt response, as it might > >(in one extreme) be a message where everything are encrypted. > > This is exactly why I don't like the idea of generic key management > attributes. If there are no common parameters, why try to merge the > signalling? > > >> If, however, they're opaque and used solely by a particular > >> protocol, then > >> I don't see the advantage of trying to make the attribute > >> generic. Why use > >> a=keymgmt-prot:MIKEY > >> a=keymgmt-data: > >> instead of > >> a=mikey: > >> when non-MIKEY speakers won't understand the attribute in > either case? > >> > > > >>From a MIKEY point of view, I do not care if it is general or > >not. However, as other people have expressed interest in > >using an attribute like this, I think it might be good to have > >something that is generic enough so you don't have to specify > >a new attribute if you like to replace MIKEY with something else. > >As I pointed out before, the approach we are using seems to be > >equal to the "fmtp" approach where SDP does not need to > >understand the content and where it is not necessary to create > >a new attribute each time you like to change/replace another > >key mgmt protocol. > > For each key exchange protocol, you need to map it onto the offer - > answer model (or other SDP usage scenario), define the syntax of the > keying information, and register the name of the keying protocol. > > With "a=keymgmt-prot:" you have defined a new IANA registry of key > exchange protocol names, and for each protocol you need to register > an entry there and define how it is used. With an SDP attribute for > each key exchange protocol, the only difference is that the name is > registered in the SDP attribute namespace. The same parameters need > to be defined. > > I don't see how the generic attributes make this process easier? This was originally related to Stephen's comment, which apparently wasn't a big problem. So, is your recommendation then that we should register a unique a=mikey: attribute (and similar for RTSP?) instead of going on with the approach in the current draft? How would you like us to proceed? Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 11:04:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26294 for ; Mon, 8 Apr 2002 11:04:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11924; Mon, 8 Apr 2002 10:59:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11894 for ; Mon, 8 Apr 2002 10:59:07 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26107 for ; Mon, 8 Apr 2002 10:59:02 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g38Ewrs7015131 for ; Mon, 8 Apr 2002 16:58:53 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA23092; Mon, 8 Apr 2002 16:58:53 +0200 Message-ID: <3CB1B02D.3040409@era.ericsson.se> Date: Mon, 08 Apr 2002 16:58:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: multipart/mixed; boundary="------------090507030702010505030700" Subject: [MMUSIC] RTSP header table version 1 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------090507030702010505030700 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, I have now a first ready version of the RTSP headers table. There are some things to do before we can consider it completed, see to do list in document. Any comments on improvents or questions regarding validity is very much welcome. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se --------------090507030702010505030700 Content-Type: text/plain; name="rtspheadertable_v1.txt" Content-Disposition: inline; filename="rtspheadertable_v1.txt" Content-Transfer-Encoding: 7bit RTSP method and header tables version 1 To Do: - Check so no header has been missed - Resolve the ? in when a header is applicable. - Decide on usage of error message bodies. - Write up proxy operations for the headers needing one. ------------------------------------------------------------------------------- Methods method direction object requirement acronym Body DESCRIBE C->S P,S recommended DES r ANNOUNCE C->S, S->C P,S optional ANN R GET_PARAMETER C->S, S->C P,S optional GPR R,r OPTIONS C->S, S->C P,S required OPT (S->C: optional) PAUSE C->S P,S recommended PSE PLAY C->S P,S required PLY RECORD C->S P,S optional REC REDIRECT S->C P,S optional RDR SETUP C->S S required STP SET_PARAMETER C->S, S->C P,S optional SPR R,r? TEARDOWN C->S P,S required TRD Table 2: Overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. Body notes if a method is allowed to carry body and in which direction, R = Request, r=response. Note: There has been some usage of the body to convey more information in error messages for responses containing error codes. Some error messages seem to mandate such usage. Headers The general syntax for header fields is covered in Section 4.2. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [?]. Examples of each header field are given. Information about header fields in relation to methods and proxy processing is summarized in Table 3. The "where" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the "where" column indicates that the header field may be present in all requests and responses. The "proxy" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The rest of the columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. *: The header field is required if the message body is not empty. See sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. "Optional" means that a Client/Server MAY include the header field in a request or response, and a Client/Server MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 12.33). A "mandatory" header field MUST be present in a request, and MUST be understood by the Client/Server receiving the request. A mandatory response header field MUST be present in the response, and the header field MUST be understood by the Client/Server processing the response. "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the Client/Server receiving the request. Similarly, a header field labeled "not applicable" for a response means that the Client/Server MUST NOT place the header field in the response, and the Client/Server MUST ignore the header field in the response. A Client/Server SHOULD ignore extension header parameters that are not understood. The From, Location, and RTP-Info header fields contain a URI. If the URI contains a comma, or semicolon, the URI MUST be enclosed in double quotas ("). Any URI parameters are contained within these quotas. If the URI is not enclosed in double quotas, any semicolon- delimited parameters are header-parameters, not URI parameters. Header Where Proxy DES OPT GPR SPR ANN STP PLY RE* PSE TRD RDR Accept R o - - - - - - - - - - Accept-Encoding R o - - - - - - - - - - Accept-Language R o - - - - - - - - - - Allow 405 - - - - m - m m m - - Authorization R o o o o o o o o o o o Bandwidth R o o? - o - o o - - - - Blocksize R o - - o - o o - - - - Cache-Control - - - - - o - - - - - Conference R - - - - - o - - - - - Connection o o o o o o o o o o o Content-Base R - - o o o - - - - - - Content-Base r o - o o - - - - - - - Content-Base 4xx o o o o o o o o o o o Content-Encoding R - - o o o - - - - - - Content-Encoding r o - o o - - - - - - - Content-Encoding 4xx o o o o o o o o o o o Content-Language R - - o o o - - - - - - Content-Language r o - o o - - - - - - - Content-Language 4xx o o o o o o o o o o o Content-Length R - - * * * - - - - - - Content-Length r * - * * - - - - - - - Content-Length 4xx * * * * * * * * * * * Content-Location R - - o o o - - - - - - Content-Location r o - o o - - - - - - - Content-Location 4xx o o o o o o o o o o o Content-Type R - - * * * - - - - - - Content-Type r * - * * - - - - - - - Content-Type 4xx * * * * * * * * * * * CSeq Rc m m m m m m m m m m m Date o o o o o o o o o o o Expires r o - - - - - - - - - - From o o o o o o o o o o o Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR If-Modified-Since R o - - - - o - - - - - Last-Modified R o - o o - o - - - - - Last-Modified R - - o o o o - - - - - Location R - - - - - - - - - - m Location 3xx m - -? -? -? m -? -? -? - - Proxy-Authenticate 407 m m m m m m m m m m m Proxy-Require R o o o o o o o o o o o Public r - m* - - - - - - - - - Public 501 m* m* m* m* m* m* m* m* m* m* m* Range R - - - - - - o - o - o Range r - - - - - - m* - - - - Referer R o o o o o o o o o o o Require R o o o o o o o o o o o Retry-After 3xx,503 o - -? -? -? o -? -? -? - - RTP-Info r - - - - - - m - - - - Scale - - - - - - o o - - - Session R - o o o m o m m m m m Session r - c c c m c m m m m m Server R - o o o o - - - - - o Server r o o o o o o o o o o - Speed - - - - - - o - - - - Transport - - - - - m - - - - - Unsupported r c c c c c c c c c c c User-Agent R m* m* m* m* m* m* m* m* m* m* - User-Agent r - - - - - - - - - - m* Vary r c c c c c c c c c c - Via R amr o o o o o o o o o o o Via c dr m m m m m m m m m m m WWW-Authenticate 401 m m m m m m m m m m m Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR Table 3: Overview of how headers are to be be used for different methods. --------------090507030702010505030700-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 13:00:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29845 for ; Mon, 8 Apr 2002 13:00:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21323; Mon, 8 Apr 2002 12:50:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA21290 for ; Mon, 8 Apr 2002 12:50:27 -0400 (EDT) Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29620 for ; Mon, 8 Apr 2002 12:50:24 -0400 (EDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GU900201DF1D0@firewall.wcom.com> for mmusic@ietf.org; Mon, 8 Apr 2002 16:49:49 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GU9001ANDF02T@firewall.wcom.com>; Mon, 08 Apr 2002 16:49:49 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GU900D01DEZI3@dgismtp01.wcomnet.com>; Mon, 08 Apr 2002 16:49:48 +0000 (GMT) Received: from skanchina ([166.50.77.73]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GU900D14DEIB8@dgismtp01.wcomnet.com>; Mon, 08 Apr 2002 16:49:31 +0000 (GMT) Date: Mon, 08 Apr 2002 12:06:02 -0500 From: Sharma Kanchinadham To: rkumar@cisco.com Cc: mmusic@ietf.org Reply-to: sharma.kanchinadham@wcom.com Message-id: <001a01c1df1f$aa2bc520$494d32a6@wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Reg Generic Format Parameter Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Rajesh, This is in reference to: http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt Section 4 provides an example: An example media description in SDP might be: m=audio 3456 RTP/AVP 0 15 98 99 a=rtpmap:98 PCMU/8000 a=gfmtp:98 vbd=on a=rtpmap:99 G726-32/8000 a=fmtp:99 vbd=on Should the highlighted line above be a =gfmtp:99 vbd=on Thanks , Sharma Kanchinadham IP Call Processing & Standards Worldcom sharma.kanchinadham@wcom.com ============================================================================ ================== _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 19:47:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10417 for ; Mon, 8 Apr 2002 19:47:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23107; Mon, 8 Apr 2002 19:44:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23070 for ; Mon, 8 Apr 2002 19:44:52 -0400 (EDT) Received: from purple.nge.isi.edu (wireless74.east.isi.edu [65.114.168.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10274 for ; Mon, 8 Apr 2002 19:44:49 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g38NinmW001443; Mon, 8 Apr 2002 19:44:50 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204082344.g38NinmW001443@purple.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Mon, 08 Apr 2002 15:13:09 +0200." <0DAEDF148988D411BB980008C7E65D2E04FE414B@esealnt416> Date: Mon, 08 Apr 2002 19:44:49 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Fredrik Lindholm (ERA)" writes: ... >So, is your recommendation then that we should register a unique >a=mikey: >attribute (and similar for RTSP?) instead of going on with the >approach in the current draft? How would you like us to proceed? I think it depends on how many key management protocols we're likely to see. If MIKEY is the only one, then a=mikey: is appropriate. But, if we expect to have many key exchange protocols, Steve's concerns about name space pollution are important, and an "a=key-mgmt:mikey " attribute may be better (because it establishes a separate namespace for key exchange protocol names). However, my main concern is the use of opaque (to SDP) data in the first place. I'd be much happier if the key exchange could happen as part of a standard offer/answer within SDP, rather than being tunneled. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 20:48:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11521 for ; Mon, 8 Apr 2002 20:48:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25568; Mon, 8 Apr 2002 20:44:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA25536 for ; Mon, 8 Apr 2002 20:44:06 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11497 for ; Mon, 8 Apr 2002 20:44:03 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g390hZON022498; Mon, 8 Apr 2002 17:43:35 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA20733; Mon, 8 Apr 2002 17:43:34 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: Cc: Subject: RE: [MMUSIC] Reg Generic Format Parameter Date: Mon, 8 Apr 2002 17:43:35 -0700 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.2910.0) In-Reply-To: <001a01c1df1f$aa2bc520$494d32a6@wcomnet.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Thanks for catching the typo. Yes, this should be changed to gfmtp. Rajesh > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Sharma Kanchinadham > Sent: Monday, April 08, 2002 10:06 AM > To: rkumar@cisco.com > Cc: mmusic@ietf.org > Subject: [MMUSIC] Reg Generic Format Parameter > > > Rajesh, > > This is in reference to: > > http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gf mtp-00.txt Section 4 provides an example: An example media description in SDP might be: m=audio 3456 RTP/AVP 0 15 98 99 a=rtpmap:98 PCMU/8000 a=gfmtp:98 vbd=on a=rtpmap:99 G726-32/8000 a=fmtp:99 vbd=on Should the highlighted line above be a =gfmtp:99 vbd=on _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 21:06:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11923 for ; Mon, 8 Apr 2002 21:06:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27238; Mon, 8 Apr 2002 21:02:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA27168 for ; Mon, 8 Apr 2002 21:02:14 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11821; Mon, 8 Apr 2002 21:02:11 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3911hON029218; Mon, 8 Apr 2002 18:01:43 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id SAA28929; Mon, 8 Apr 2002 18:01:41 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Stephen Casner" , "Tom-PT Taylor" Cc: , Subject: RE: [MMUSIC] Silence Suppression Attribute Date: Mon, 8 Apr 2002 18:01:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020403165246.Q48839-100000@ash.packetdesign.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Stephen Casner > Sent: Wednesday, April 03, 2002 6:06 PM > To: Tom-PT Taylor > Cc: mmusic@ietf.org; megaco@ietf.org > Subject: Re: [MMUSIC] Silence Suppression Attribute > It may have been a mistake to include the a=silenceSupp attribute for > ATM without considering the problem more generally. I suspect that > RFC 3108 did not get much attention in MMUSIC because many of the > participants don't care much about ATM. Steve, A little bit of history on why there is a silence suppression attribute for ATM in RFC3108. Let us look at AAL2 first, and then at AAL1. If you look at the AAL2 profiles in ITU I.366.2, it is possible to support PCM or ADPCM without silence suppression. Supporting silence suppression is not mandatory for all AAL2 connections along the lines of the "strong requirement" you quoted for silence suppression in the RTP context. Why would I.366.2 make it optional for AAL2, and not mandatory as you made it for RTP? Here is a possible justification: The optional nature of silence suppression might be taken advantage of to reduce DSP costs. PCM without silence suppression does not need a DSP, ADPCM without silence suppression can be implemented in a non-DSP hardwired processor. Now, moving from AAL2 to AAL1: it goes without saying that silence suppression is completely optional in the AAL1 context. It is rarely used with PCMU/PCMA on AAL1, however, there is nothing to preclude its use (except there exists no SID mechanism for AAL1, as there exists for AAL2). Does the inclusion of this attribute in the ATM context seem more reasonable in this light now? Rajesh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 21:14:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12217 for ; Mon, 8 Apr 2002 21:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28087; Mon, 8 Apr 2002 21:12:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28032 for ; Mon, 8 Apr 2002 21:12:32 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12170; Mon, 8 Apr 2002 21:12:29 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g391BlCl014975; Mon, 8 Apr 2002 18:11:47 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id SAA04196; Mon, 8 Apr 2002 18:12:00 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Mmusic@Ietf. Org" , "Megaco@Ietf. Org" , "Stephen Casner" , "Tom-PT Taylor" Date: Mon, 8 Apr 2002 18:12:01 -0700 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.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RFC 3108 passed without adequate scrutiny? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Stephen Casner > Sent: Wednesday, April 03, 2002 6:06 PM > To: Tom-PT Taylor > Cc: mmusic@ietf.org; megaco@ietf.org > Subject: Re: [MMUSIC] Silence Suppression Attribute > It may have been a mistake to include the a=silenceSupp attribute for > ATM without considering the problem more generally. I suspect that > RFC 3108 did not get much attention in MMUSIC because many of the > participants don't care much about ATM. Another point on "rfc3108 passing without due scrutiny": There was a lively discussion on the ATM SDP issues both on 'cnfcntrl' mailing list (which preceded the present one), and on a separate mailing list "atmsdp" dedicated to this subject. I think I made it a point to cross-copy cnfcntrl@ietf.org on all messages. Please read on for a justification of the silence suppression parameter in rfc3108, which should be obvious to all ATM folks: Steve, A little bit of history on why there is a silence suppression attribute for ATM in RFC3108. Let us look at AAL2 first, and then at AAL1. If you look at the AAL2 profiles in ITU I.366.2, it is possible to support PCM or ADPCM without silence suppression. Supporting silence suppression is not mandatory for all AAL2 connections along the lines of the "strong requirement" you quoted for silence suppression in the RTP context. Why would I.366.2 make it optional for AAL2, and not mandatory as you made it for RTP? Here is a possible justification: The optional nature of silence suppression might be taken advantage of to reduce DSP costs. PCM without silence suppression does not need a DSP, ADPCM without silence suppression can be implemented in a non-DSP hardwired processor. Now, moving from AAL2 to AAL1: it goes without saying that silence suppression is completely optional in the AAL1 context. It is rarely used with PCMU/PCMA on AAL1, however, there is nothing to preclude its use (except there exists no SID mechanism for AAL1, as there exists for AAL2). Does the inclusion of this attribute in the ATM context seem more reasonable in this light now? Rajesh ------------ Rajesh Kumar Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 8 21:25:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12656 for ; Mon, 8 Apr 2002 21:25:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28842; Mon, 8 Apr 2002 21:24:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28805 for ; Mon, 8 Apr 2002 21:24:31 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12598; Mon, 8 Apr 2002 21:24:28 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g391O0q6027878; Mon, 8 Apr 2002 18:24:00 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id SAA09011; Mon, 8 Apr 2002 18:23:57 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Dan Firac" , "Colin Perkins" Cc: , Subject: RE: [MMUSIC] Silence Suppression Attribute Date: Mon, 8 Apr 2002 18:23:58 -0700 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.2910.0) In-Reply-To: <005d01c1ded2$c53703e0$1b00a8c0@softtel.ro> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Dan, Regarding your comment on http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt : > 2) (for rajesh) I think inserting 'ecan' in your parameter list is not > a wise thing to do. Because the echo cancelation is NOT a > codec parameter (you won't find the echo cancelation block as > an codec integrated part, but as a separate one !!!). As far as I > know the echo cancelation block operates (at receiver) AFTER > the codec. So, I think 'ecan' may be moved to media level. The list of parameters is not complete, nor is it intended to be. Further, it is for exemplary purposed only. However, let us look at ECAN further. H.248 and MGCP do allow ECAN to be indicated per connection, why should SIP offer/answer be precluded from doing so? Further, H.248 would use SDP/tags for the MGC to enable/disable ECAN per connection, since it does not have the equivalent of the local connection option in MGCP. However, your statement that ECAN is not codec-specific is quite right. Maybe, you need a media-level parameter such as a=ecan, of the kind that you have in rfc3108. > Given the above opinions and the fact that the 'gftmp' parameter > values would not differ from codec to codec, For the 'vbd' parameter, they would. We do need it to be at the codec level. >I think the 'gfmtp' > can be moved to media level, and any particular parameters > for a certain codec should be expressed with 'ftmp' (This is > the definition o 'fmtp': format SPECIFIC parameters). 'fmtp' refers to those format specific parameters that are part of the MIME definition. 'gfmtp' refers to those that are not an integral part of the MIME definition, but can be applied selectively (and optionally) to codecs at the time of call establishment. What does the team think? Rajesh Kumar > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 01:47:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18612 for ; Tue, 9 Apr 2002 01:47:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20253; Tue, 9 Apr 2002 01:27:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20191 for ; Tue, 9 Apr 2002 01:27:03 -0400 (EDT) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18322; Tue, 9 Apr 2002 01:26:59 -0400 (EDT) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g395PN026470; Tue, 9 Apr 2002 15:25:23 +1000 (EST) Received: from ericsson.com.au (dhcp-239-110.epa.ericsson.se [146.11.239.110]) by brsf10.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA03037; Tue, 9 Apr 2002 15:26:53 +1000 (EST) Message-ID: <3CB26115.48BFB6D2@ericsson.com.au> Date: Tue, 09 Apr 2002 13:33:41 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rkumar@cisco.com CC: Dan Firac , Colin Perkins , mmusic@ietf.org, avt@ietf.org Subject: Re: [AVT] RE: [MMUSIC] Silence Suppression Attribute 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hello Rajesh, One of your statements confuses me: ..snip.. > However, let us look at ECAN further. H.248 and MGCP do allow ECAN to be > indicated per connection, why should SIP offer/answer be precluded from > doing so? Further, H.248 would use SDP/tags for the MGC to enable/disable > ECAN per connection, since it does not have the equivalent of the local > connection option in MGCP. > H.248/Megaco has a package property to indicate Echo Cancellation. This is listed in the Local Control descriptor not under local and remote. So for H.248 the MGC does not use SDP for Echo cancellation. Regards, Christian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 03:34:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28435 for ; Tue, 9 Apr 2002 03:34:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA26055; Tue, 9 Apr 2002 03:14:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA25989 for ; Tue, 9 Apr 2002 03:14:28 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28106 for ; Tue, 9 Apr 2002 03:14:24 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g397EG3G015029; Tue, 9 Apr 2002 09:14:16 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA17178; Tue, 9 Apr 2002 09:14:16 +0200 Message-ID: <3CB294C6.20404@era.ericsson.se> Date: Tue, 09 Apr 2002 09:14:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gayathri Ramakrishnan CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP header table version 1 References: <3CB1B02D.3040409@era.ericsson.se> <3CB28437.D33A9B51@npd.hcltech.com> Content-Type: multipart/mixed; boundary="------------050304040605090908050102" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------050304040605090908050102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Gayathri, I also reply to the MMUSIC WG which is the place to discuss/inform about RTSP stuff. Thank you for the proposal, I think we have to wait until the feature negotiation mechanism is finished and we have defined the couple of different features that we know this far, until we update the chapter on implementation requirements. My guess is that by reviewing the minimal implementation for server and client we can see if that is clear enough on what is needed for implementation. To that chapter I think we should add the different features defined and which extra header and functionality is need compared to the minimum implementation. Doing that work we will see if something like http summary tables is required or not. Cheers Magnus Gayathri Ramakrishnan wrote: >Hi, >For more clarity of the doc, you also try to add / follow >some style which has been adopted in the HTTP1.1 requirement >summary doc. This contains a tabulation which is clearer >as to what the client/server/proxy has to implement along >with reference to the appropriate sections. >Please find the doc attached. > >Hope this helps. >- Gayathri > >Magnus Westerlund wrote: > >> -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se --------------050304040605090908050102 Content-Type: text/plain; name="Http1.1-req.txt" Content-Disposition: inline; filename="Http1.1-req.txt" Content-Transfer-Encoding: 8bit HTTP Working Group R. Patterson, Sterling Software Internet-Draft 20 October 1998 Expires: 20 April 1999 HTTP/1.1 Requirements Summary draft-patterson-http-req-sum-00.txt STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the HTTP working group at . Discussions of the working group are archived at . General discussions about HTTP and the applications which use HTTP should take place on the mailing list. ABSTRACT RFC1122 ?1Ù introduced a ``Requirements Summary'' format, to help implementors understand what aspects of a lengthy specification were mandatory, recommended, or optional. The HTTP/1.1 specification is similarly lengthy and complicated; many implementors have asked for guidance in understanding what they need to do. Patterson ?Page 1Ù Internet-Draft HTTP requirements summary 20 October 1998 TABLE OF CONTENTS 1 Introduction 1 2 Categorizing implementations 2 2.1 Introductory material for Requirements Summary 2 3 Requirements summary for Section 1: Introduction 4 4 Requirements summary for Section 2: Notational Conventions and Generic Grammar 4 5 Requirements summary for Section 3: Protocol Parameters 5 6 Requirements summary for Section 4: HTTP Message 6 7 Requirements summary for Section 5: Request 7 8 Requirements summary for Section 6: Response 8 9 Requirements summary for Section 7: Entity 8 10 Requirements summary for Section 8: Connections 9 11 Requirements summary for Section 9: Method Definitions 10 12 Requirements summary for Section 10: Status Code Definitions 11 13 Requirements summary for Section 11: Access Authentication 13 14 Requirements summary for Section 12: Content Negotiation 13 15 Requirements summary for Section 13: Caching in HTTP 14 16 Requirements summary for Section 14: Header Field Definitions 16 17 Requirements summary for Section 15: Security Considerations 22 18 Requirements summary for Section 16: Acknowledgments 22 19 Requirements summary for Section 17: References 22 20 Requirements summary for Section 18: Authors' Addresses 23 21 Requirements summary for Section 19: Appendices 23 22 Requirements summary for Section 20: Full Copyright Statement 23 23 Requirements summary for Section 21: Index 23 24 Security Considerations 23 25 Acknowledgments 24 26 References 24 27 Author's address 24 1 Introduction RFC1122 ?1Ù introduced a ``Requirements Summary'' format, to help implementors understand what aspects of a lengthy specification were mandatory, recommended, or optional. The HTTP/1.1 specification is similarly lengthy and complicated; many implementors have asked for guidance in understanding what they need to do. This is especially important because there are several kinds of HTTP/1.1 implementations (including server, proxy, and client, with or without caches). Many aspects of the specification apply only to a subset of these implementation categories, which means that someone implementing, say, an HTTP client must disentangle the client-specific requirements from the (client-irrrelevant) requirements for servers and proxies. Patterson ?Page 2Ù Internet-Draft HTTP requirements summary 20 October 1998 2 Categorizing implementations The format of the Requirements Summary is designed so that it is readable even in the plain-ASCII version of the HTTP/1.1 specification, since this is the ``official'' version of an IETF specification. This places some constraints on the number of columns in the format, which in turn constrains the number of categories that can be comfortably included. Although at first glance, there might appear to be at least six different implementation categories (server, proxy, client, each with or without a cache). However, in many sections of the HTTP specification, caching is irrelevant. For many other features, it is fairly obvious whether the feature applies to a cache or not. Therefore, this document uses a format where the applicability of a requirement to an caching implementation is signalled by a footnote, rather than expanding the number of columns to six. 2.1 Introductory material for Requirements Summary ?This is repeated more or less verbatim from section 19.9 of ?2Ù, for the benefit of the reader.Ù This section summarizes the requirements of the HTTP/1.1 specification. (Requirements are those aspects of the protocol defined with the words "MUST", "SHOULD", or "MAY.") This list is not a normative part of the HTTP/1.1 specification, and if there is any conflict between this listing and another part of the specification, the statements elsewhere in the specification take absolute priority. Requirements are listed in the order that they appear in the the specification. For each requirement, the list includes - a very brief summary of the feature; this is meant for identification purposes only, and must not be used as a specification of the feature. - the section of the document in which the feature is specified. - A column for each of three categories of implementation (Server, Proxy, and Client), showing whether the listed feature is a MUST, SHOULD, or MAY requirement. - A column for additional footnotes Note that some aspects of Patterson ?Page 3Ù Internet-Draft HTTP requirements summary 20 October 1998 the protocol may be specified in multiple sections in separated part of the document. In order to fit into the standard IETF format for ASCII text documents, some of the column headings, and the requirement keywords, are abbreviated. ?End of extract from ?2Ù.Ù Key for column headings: Srvr = Server Prox = Proxy Clnt = Client Key for requirements keywords: M = MUST MN = MUST NOT S = SHOULD SN = SHOULD NOT ok = MAY na = Not applicable Some entries are listed as ``MUST NOT'' or ``SHOULD NOT'' even if the feature summary seems to indicate a ``MUST'' or ``SHOULD''. The entries reflect the words from the actual spec, rather than the feature summary. I.e., the feature summary wording is only to help the reader find the appropriate passage; it is in no way a definitive description of the requirement! 3 Requirements summary for Section 1: Introduction ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== "proxy" definition 1.3 na M na 586 4 Requirements summary for Section 2: Notational Conventions and Generic Grammar ... text about variations from the norm ... Notes: 1 ... Patterson ?Page 4Ù Internet-Draft HTTP requirements summary 20 October 1998 Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== 857 2.1 Augmented BNF (",") and OPTIONAL linear white space (LWS). This makes the usual 1# requires at least one 2.1 M M M 866 Tokens must be delimited 2.1 M M M 883 Replace LWS with SP 2.2 ok ok ok 934 TEXT allows non-ISO-8859-1 2.2 ok ok ok 941 Specials in parms must be quoted 2.2 M M M 964 Backslash enquotes single chars 2.2 ok ok ok 991 5 Requirements summary for Section 3: Protocol Parameters ... text about variations from the norm ... Notes: 1 Applies to caching proxies only. 2 Applies to gateways only. 3 Applies to tunnels only. 4 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== HTTP-Version is two integers 3.1 M M M 1025 HTTP-Version can be multi digits 3.1 ok ok ok 1026 Accept HTTP-Version w/ lzeroes 3.1 M M M 1028 Send HTTP-Version w/ lzeroes 3.1 MN MN MN 1029 HTTP-Version=HTTP/1.1 cond. comp. 3.1 M M M 1032 Send HTTP/1.1 if at least cond comp. 3.1 S S S 1034 Send HTTP/1.1 for non-HTTP/1.0 msgs 3.1 M M M 1035 Send HTTP-Version > actual 3.1 na MN na 1045 Downgrade higher HTTP-Version 3.1 na M na 1047 Upgrade HTTP-Version to highest 3.1 na M na 1 1052 Upgrade HTTP-Version to highest 3.1 na ok na 2 1053 Upgrade HTTP-Version to highest 3.1 na MN na 3 1053 Resp. HTTP-Version major like request 3.1 na M na 1054 URI size must hold all for server 3.2.1 M M? na 1091 URL size unbounded for GET forms 3.2.1 S S? na 1092 Send 414 for URI too long 3.2.1 S S? na 1094 Avoid IP addrs in URLs 3.2.2 S S S 1114 abs_path='' => abs_path='/' 3.2.2 na? M M 1115 Add domain to host name 3.2.2 na ok na 1118 Change host name 3.2.2 na MN na 1119 Case sensitive URI comparison 3.2.3 na S S 1126 Host names case insensitive 3.2.3 na M M 1131 Scheme names case insensitive 3.2.3 na M M 1132 Accept all three date formats 3.3.1 M M M 1163 Send RFC 1123 date format 3.3.1 M M M 1164 Send date/time in GMT 3.3.1 M M M 1173 Patterson ?Page 5Ù Internet-Draft HTTP requirements summary 20 October 1998 Assume GMT for asctime format 3.3.1 M M M 1177 Include LWS in HTTP-date 3.3.1 MN MN MN 1178 MIME character set is complete 3.4 M M M 1246 Honor IANA character set names 3.4 M M M 1267 Use only IANA character set names 3.4 S S S 1268 Send charset if ISO-8859-1 3.4.1 ok ok ok 1279 Send charset if ISO-8859-1 and safe 3.4.1 S S S 1280 Respect charset label 3.4.1 M M M 1284 Respect Content-Type charset label 3.4.1 M M M 1286 Equate x-gzip and x-compress 3.5 S S S 1332 Send identity in Content-Encoding 3.5 SN SN SN 1342 Register new content-coding tokens 3.5 S S S 1344 Publicly available content-codings 3.5 S S S 1346 Chunked when not closing connection 3.6 M M M 1376 Chunked is last transfer-coding 3.6 M M M 1383 Apply chunked > 1 time 3.6 MN MN MN 1384 Register new transfer-coding tokens 3.6 S S S 1402 Send 501 when transfer-coding unknown 3.6 S S na 1406 Send transfer-codings to HTTP/1.0 3.6 MN MN na 1407 1415 3.6.1 Chunked Transfer Coding followed by an OPTIONAL trailer containing entity-header fields. This Trailer header fields with chunked 3.6.1 MN MN na 1456 Receive and decode chunked t-coding 3.6.1 M M M 1481 Ignore unknown chunk-extensions 3.6.1 M M M 1482 Parameters follwing type/subtype 3.7 ok ok ok 1503 LWS between type and subtype 3.7 MN MN MN 1509 LWS between attribute and value 3.7 MN MN MN 1509 Avoid m-type parms for HTTP/1.0 3.7 S S S 1516 Send non-TEXT in canonical form 3.7.1 M M M 1528 Accept CR and LF in TEXT as CRLF 3.7.1 M M M 1536 Subsitute CR or LF for CRLF in hdrs 3.7.1 MN MN MN 1544 Canonical form before content-coding 3.7.1 M M M 1548 Label non-ISO-8859-1 data. 3.7.1 M M M 1555 Multipart boundary required 3.7.2 M M M 1568 CRLF only separator in multipart 3.7.2 M M M 1569 No multipart epilogue 3.7.2 M M M 1571 Transmit multipart epilogue 3.7.2 MN MN MN 1572 UA follow MIME-UA multipart behavior 3.7.2 na S S 1583 UA follow MIME-UA behavior 3.7.2 na S S 1589 Handle unknown multipart as mixed 3.7.2 M M M 1592 Short direct product tokens 3.8 S S S 1623 Non-essential info in product tokens 3.8 MN MN MN 1623 Any character in product version 3.8 ok ok ok 1625 Product version for version only 3.8 ok ok ok 1625 Product versions only change version 3.8 ok ok ok 1627 qvalue with > 3 digits after dot 3.9 MN MN MN 1639 Limit config of qvalue to 3 digits 3.9 S S S 1640 Share strong entity tag if congruent 3.11 ok ok ok 1703 Share weak entity tag if equivalent 3.11 ok ok ok 1706 Unique entity tag for versions of ent. 3.11 M M M 1711 ???entity tag??? 3.11 ok ok ok 1712 Ignore non-byte ranges 3.12 ok ok ok 1732 6 Requirements summary for Section 4: HTTP Message Patterson ?Page 6Ù Internet-Draft HTTP requirements summary 20 October 1998 ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Ignore empty lines before request 4.1 S S na 1767 Ignore CRLF before request 4.1 S S na 1770 Preface or follow request w/ extra CRLF 4.1 na MN MN 1774 Preceed field values with LWS 4.2 ok ok ok 1785 Follow "common form" 4.2 S S S 1788 Remove lead/trail LWS from field values 4.2 ok ok ok 1811 Replace LWS w/ SP in field values 4.2 ok ok ok 1813 Split field into multiples if #(values) 4.2 ok ok ok 1822 Possible to combine split fields 4.2 M M M 1825 Reorder split fields 4.2 na MN na 1830 Indicate t-codings in Transger-Encoding 4.3 M M M 1845 Add or remove t-codings 4.3 ok ok ok 1848 Send msg body if method doesn't allow 4.3 na MN MN 1857 Consume and forward all msg bodies 4.3 S S na 1864 Ignore msg body if method doesn't allow 4.3 S S na 1867 Send msg body with HEAD response 4.3 MN MN na 1872 Send msg body with 1xx, 204, 304 resp. 4.3 MN MN na 1875 Send zero-length msg body for others 4.3 ok ok na 1876 Terminate no-body resp after header 4.4 ? ? ? 1887 Honor Content-Length w/ Transfer-Enc.? 4.4 MN MN MN 1900 Use multi/byteranges when unsure 4.4 MN MN MN 1907 Send Content-Length if unsure HTTP 1.1 4.4 M M M 1928 Resp 400/411 if body and no Content-Len 4.4 S S na 1931 Accept chunked 4.4 M M M 1935 Send Content-Length w/ non-identity 4.4 MN MN MN 1940 Ignore Content-Length w/ non-identity 4.4 M M M 1942 Content-Length match octets in body 4.4 M M M 1945 Notify user when invalid length rec'd 4.4 na na M 1946 7 Requirements summary for Section 5: Request ... text about variations from the norm ... Notes: 1 Requirement only applies to "general purpose" servers. 2 Requirement only applies to "transparent proxies". 3 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Patterson ?Page 7Ù Internet-Draft HTTP requirements summary 20 October 1998 Respond 405 in unimplemented but known 5.1.1 S S na 2026 Support GET and HEAD 5.1.1 M M na 1 2029 2031 5.1.1 Method OPTIONAL; however, if the above methods are implemented, they MUST be Implement optional meths correctly 5.1.1 M M na 2031 2058 5.1.2 Request-URI The absoluteURI form is REQUIRED when the request is being made to a Forward request through proxy 5.1.2 na ok na 2060 Recognize self in absoluteURI 5.1.2 na M na 2063 Accept absoluteURI in request 5.1.2 M M na 2070 Send abs_path for origin server 5.1.2 na M M 2078 Send Host for origin server 5.1.2 na M M 2079 Send null path as "/" in abs_path 5.1.2 na M M 2089 Decode url-encoded Request-URI 5.1.2 M M na 2094 Respond to invalid Request_URI approp. 5.1.2 S S na 2095 Rewrite abs_path when forwarding 5.1.2 na MN na 2 2103 Ignore Host if not used by server 5.2 ok na na 2120 Honor Host rules if used by server 5.2 M na na 2126 Ignore Host if Request-URI is absolute 5.2 M na na 2130 Send 400 response for host problems 5.2 M na na 2138 Guess host if HTTP/1.0 w/o Host 5.2 ok na na 2141 Recognize extension request-headers 5.3 ok ok na 2182 8 Requirements summary for Section 6: Response ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Replace response text 6.1.1 ok ok na 2249 Recognize status-code class 6.1.1 na M M 2306 Cache unrecognized status 6.1.1 na MN MN 2310 Present entity w/ unrec. status to user 6.1.1 na na S 2314 Recognize extension response-headers 6.2 na ok ok 2343 9 Requirements summary for Section 7: Entity ... text about variations from the norm ... Notes: 1 Requirement only applies to "transparent proxies". 2 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Message contains entity if not forbid. 5 ok ok ok 2351 2364 7.1 Entity Header Fields Some of this metainformation is OPTIONAL; some might be REQUIRED by 2364 7.1 Entity Header Fields Some of this metainformation is OPTIONAL; some might be REQUIRED by Ignore unrecognized headers 7.1 S S S 2384 Forward unrecognized headers 7.1 na M na 1 2384 Send Content-Type with msg body 7.2.1 S S S 2421 Patterson ?Page 8Ù Internet-Draft HTTP requirements summary 20 October 1998 Guess media type if no Content-Type 7.2.1 ok ok ok 2424 Treat unrecognized m. t. as appl/oct. 7.2.1 S S S 2426 10 Requirements summary for Section 8: Connections ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Implement persistent connections 8.1.1 S S S 2481 Assume persistent connection 8.1.2 na S S 2489 Send requests after Connection: Close 8.1.2 na MN MN 2495 Assume persistent conn unless C: Close 8.1.2.1 ok ok na 2501 Send Connection: Close for non-pers. c. 8.1.2.1 S S na 2505 ??? 8.1.2.1 ? ? ? 2508 Send Connection: Close for non-pers. c. 8.1.2.1 na S S 2512 Assume persistent conn. for HTTP < 1.1 8.1.2.1 SN SN SN 2523 All msgs on p. c. have self-defined len 8.1.2.1 M M M 2528 Pipeline requests on persistent conn. 8.1.2.2 na ok ok 2535 Send responses in request order 8.1.2.2 M M na 2537 Retry connection if pipelining fails 8.1.2.2 na S S 2541 Retry pipelined requests until persis. 8.1.2.2 na MN MN 2543 Retry pipelined reguests after close 8.1.2.2 na M M 2544 Pipeline non-idempotent requests 8.1.2.2 na MN MN 2548 Wait before sending non-idempotent req. 8.1.2.2 na S S 2552 Signal pers. con. sep. to client&server 8.1.3 na M na 2561 Establish pers con with HTTP 1.0 client 8.1.3 na MN na 2566 Close connection on timeout 8.1.4 S S S 2586 Watch constantly for connection close 8.1.4 S S S 2587 Close connection at any time 8.1.4 ok ok ok 2593 Recovcer from asynchronous close 8.1.4 M M M 2600 Reopen and retransmit requests 8.1.4 na S S 2601 Retransmit non-idempotent requests 8.1.4 na MN MN 2605 Allow user to retrans non-idem requests 8.1.4 na na ok 2605 Repeat retry if retry fails 8.1.3 na SN SN 2607 Respond to at least one request/conn. 8.1.4 S S na 2610 Close connection in middle of response 8.1.4 SN SN na 2611 Limit simultaneous persistent conns. 8.1.4 na S S 2615 Single-user client limit to 2/server 8.1.4 na na S 2617 Proxy limit to 2*n/server 8.1.4 na S na 2618 Use flow control instead of closing 8.2.1 S S na 2629 Watch for error resp during req trans 8.2.2 na S S 2645 Cease transmission on error resp 8.2.2 na S S 2647 Send zero-length chunck to terminate 8.2.2 na ok ok 2650 Close conn to terminate w/ Content-Len 8.2.2 na M M 2651 Retry idempotent requests w/o user int. 8.2.3 na ok ok 2660 Retry non-idempotent req w/o user int. 8.2.3 na SN SN 2662 Confirm by user-agent s/w 8.2.3 na ok ok 2664 Patterson ?Page 9Ù Internet-Draft HTTP requirements summary 20 October 1998 Send Expect: 100-cont. to get 100 resp 8.2.4 na M M 2680 Send Expect: 100-cont. w/o msg body 8.2.4 na MN MN 2683 Wait for 100 resp if never seen before 8.2.4 na SN SN 2692 Send 100 resp for Expect: 100-continue 8.2.4 M na na 2704 Wait for body before sending 100 8.2.4 MN na na 2707 Close connection if sending error stat. 8.2.4 ok na na 2709 Read/ignore req if sending error stat. 8.2.4 ok na na 2709 Execute req if sending error stat. 8.2.4 MN na na 2710 Send 100 if no Expect: 100-continue 8.2.4 SN na na 2713 Send 100 if no E: 100-c from HTTP 1.0 8.2.4 MN na na 2715 Send 100 if no E: 100-c on 1.1 POST/PUT 8.2.4 ok na na 2718 Omit 100 if msg body already received 8.2.4 ok na na 2727 Send final status after sending 100 8.2.4 M na na 2731 Close conn if err & no Expect: 100-cont 8.2.4 SN na na 2740 Forward Expect: 100-continue to > 1.0 8.2.4 na M na 2754 Forward Expect: 100-continue to <= 1.0 8.2.4 na MN na 2764 Send 417 if Expect: 100-cont to <= 1.0 8.2.4 na M na 2764 Cache recent HTTP-Versions from servers 8.2.4 na S na 2767 Forward 100 to HTTP 1.0 w/o Expect: 100 8.2.4 na MN na 2770 Retry request w/ msg body if no E: 100 8.2.5 na s s 2784 Back off exponentially to retry 8.2.5 na ok ok 2785 Continue backoff after error stat 8.2.5 na SN SN 2814 Close conn after error stat 8.2.5 na S S 2816 11 Requirements summary for Section 9: Method Definitions ... text about variations from the norm ... Notes: 1 ... 2 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Send Host with all requests 9 na M M 2829 GET and HEAD side effects 9.1.1 SN SN na 2844 OPTIONS and TRACE side effects 9.1.2 SN SN na 2863 Send Content-Type w/ OPTIONS if body 9.2 na M M 2896 Discard body with OPTIONS 9.2 ok na na 2900 Send optional feature hdrs w/ OPT. 200 9.2 S S na 2914 Send communication info w/ OPT. 200 9.2 S S na 2917 Use content negotiation for resp. form. 9.2 ok ok ok 2920 Send Content-Length: 0 if no body 9.2 M M ok 2922 Target proxy with Max-Forwards 9.2 na ok ok 2925 Check for Max-Forwards header 9.2 na M na 2928 Forward Max-Forwards: 0 9.2 na MN na 2929 Respond to Max-Forwards: 0 w/ comm opts 9.2 na S na 2930 Decrement Max-Forwards when forwarding 9.2 na M na 2932 Add Max-Forwards if not present 9.2 na MN na 2934 Respond to HEAD with msg body 9.4 MN MN na 2975 Patterson ?Page 10Ù Internet-Draft HTTP requirements summary 20 October 1998 HEAD hdr metainfo identical to GET 9.4 S S na 2977 Cache HEAD response 9.4 ok ok ok 2984 Update cache with HEAD response 9.4 ok ok ok 2985 HEAD response make cache entry stale 9.4 M M M 2989 Send 201 on POST if resource created 9.5 S na na 3030 POST requests follow sec. 8.2 rules 9.5 na M M 3039 Treat PUT entity as modifed version 9.6 S S na 3049 Send 201 on PUT if new resource created 9.6 M na na 3054 Send 200/204 on PUT if resource updated 9.6 S na na 3056 Send error resp on PUT if failure 9.6 S na na 3064 Ignore unrecognized Content-* hdrs 9.6 MN MN na 3065 Send 501 if unrecognized Content-* hdrs 9.6 M na na 3067 Resp to PUT makes cached entries stale 9.6 S S S 3070 Apply PUT to unidentified resource 9.6 MN na na 3080 Send 301 if PUT would update unid rsrc 9.6 M na na 3082 Decide whether to redirect on 301 9.6 na na ok 3082 One resource with many URIs 9.6 ok ok na 3086 PUT requests follow sec. 8.2 rules 9.6 na M M 3095 Apply PUT ent-hdrs to affected resource 9.6 S S na 3099 Server or human override of DELETE 9.7 ok na na 3106 Respond w/ success if not intending 9.7 SN na na 3110 Send 200/202/204 if DELETE successful 9.7 S na na 3115 Resp to DELETE makes cached ents. stale 9.7 S S S 3127 Send request as 200 resp body on TRACE 9.8 S S na 3135 Send msg body with TRACE request 9.8 na na MN 3138 Send resp msg body as message/http 9.8 S S na 3149 Cache TRACE responses 9.8 MN MN MN 3151 12 Requirements summary for Section 10: Status Code Definitions ... text about variations from the norm ... Notes: 1 Requirement applies to clients with link-editting capabilities. 2 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Send 1xx to HTTP 1.0 client 10.1 MN MN na 3174 Accept 1xx if not expecting 100 10.1 na M M 3183 Ignore unexpected 1xx responses 10.1 na ok ok 3185 Forward 1xx 10.1 na M na 3188 Continue request when 100 10.1.1 na S S 3198 Send request or ignore when 100 10.1.1 na S S 3201 Send final response when 100 10.1.1 M M na 3203 Switch protocol when advantageous 10.1.2 S S na 3217 Send info in msg body when 201 10.2.2 S S na 3258 Create resource before responding 10.2.2 M na na 3262 Send 202 in action deferred 10.2.2 S na na 3263 Patterson ?Page 11Ù Internet-Draft HTTP requirements summary 20 October 1998 Send ETag on 201 for new variant 10.2.2 ok ok na 3266 Send status info in msg body on 202 10.2.3 S S na 3284 Subset/superset metainfo on 203 10.2.4 na ok na 3293 Send updated metainfo on 204 10.2.5 ok ok na 3311 Associate metainfo w/ variant on 204 10.2.5 na S S 3312 Change document view on 204 10.2.5 na na SN 3315 Apply metainfo to view on 204 10.2.5 na na S 3319 Send msg body w/ 204 10.2.5 MN MN na 3322 Reset document view on 205 10.2.6 na na S 3328 Send msg body w/ 205 10.2.6 MN MN na 3333 Received Range to send 206 10.2.7 M M na 3339 Received If-Range to send 206 10.2.7 ok ok na 3340 Send specified hdrs w/ 206 10.2.7 M M na 3343 Content-Length match octet count on 206 10.2.7 M M na 3349 Send entity-hdrs w/ 206 if strong If-R. 10.2.7 SN SN na 3368 Send entity-hdrs w/ 206 if weak If-R. 10.2.7 MN MN na 3370 Send entity-hdrs w/ 206 if no If-Range 10.2.7 M M na 3373 Combine 206 w/ cached ent if no match 10.2.7 MN MN MN 3376 Cache 206 if no Range/Content-R. supt. 10.2.7 MN MN MN 3381 Redirect w/o user int. iff GET/HEAD 10.3 na na ok 3388 Detect infinite redirection loops 10.3 na S S 3390 Send choices in msg body if not HEAD 10.3.1 S S na 3407 Select choice automatically on 300 10.3.1 na ok ok 3412 Send preferred choice in Location 300 10.3.1 S S na 3416 Select Location choice automatically 10.3.1 na ok ok 3423 Use returned URI in future on 301 10.3.2 na S S 3430 Relink references on 301 10.3.2 na S S 1 3431 Send new URI in Location on 301 10.3.2 S S na 3436 Send note w/ new URI in body on 301 10.3.2 S S na 3438 Auto-redirect non-GET/HEAD on 301 10.3.2 na MN MN 3442 Use request-URI in future on 302 10.3.3 na S S 3454 Send temporary URI in Location on 302 10.3.3 S S na 3459 Send note w/ temp URI in body on 302 10.3.3 S S na 3461 Auto-redirect non-GET/HEAD on 302 10.3.3 na MN MN 3465 Retrieve new URI w/ GET on 303 10.3.4 na S S 3486 Cache 303 response 10.3.4 MN MN MN 3490 Send new URI in Location on 303 10.3.4 S S na 3493 Send note w/ new URI in body on 303 10.3.4 S S na 3495 Send 304 if allowed but not modified 10.3.5 S S na 3507 Send msg body on 304 10.3.5 MN MN na 3508 Send specified headers on 304 10.3.5 M M na 3511 Send entity-headers on 304 if strong 10.3.5 SN SN na 3524 Send entity-headers on 304 if weak 10.3.5 MN MN na 3526 Ignore 304 if not already cached 10.3.5 M M M 3530 Update all cache info on 304 10.3.5 M M M 3534 Send msg body on 304 10.3.5 MN MN na 3543 Use proxy identified in Location on 305 10.3.6 na M M 3549 305 genereated only by origin server 10.3.6 M M na 3552 Alter redirection over time on 307 10.3.8 ok ok na 3569 Use Request-URI in future on 307 10.3.8 na S S 3569 Send tmp URI in Location on 307 10.3.8 S S na 3574 Send note w/ tmp URI in msg body on 307 10.3.8 S S na 3576 Auto-redirect non-GET/HEAD on 307 10.3.8 na MN MN 3580 Patterson ?Page 12Ù Internet-Draft HTTP requirements summary 20 October 1998 Send tmp URI in Location on 307 10.3.8 S S na 3585 Send note in msg body on non-HEAD 4xx 10.4 S S na 3594 Display msg body on 4xx 10.4 na na S 3597 Receive client data before close on 4xx 10.4 S S na 3604 Repeat request w/o change on 400 10.4.1 na SN SN 3615 Send WWW-Authenticate on 401 10.4.2 M M na 3621 Repeat req. with Authorization on 401 10.4.2 na ok ok 3623 Present resp. body if retry gets 401 10.4.2 na na S 3629 Repeat request on 403 10.4.4 na SN SN 3644 Send reason in body on 403 10.4.4 S S na 3646 Send 410 instead of 404 if permanent 10.4.5 S S na 3656 Send Allow w/ 405 10.4.6 M M na 3672 Send choices in body on 406 10.4.7 S S na 3683 Auto-select choice on 406 10.4.7 na ok ok 3689 Stop receiving unacceptable response 10.4.7 na S S 3698 ??? 10.4.8 ? ? ? 3706 Send Proxy-Authenticate w/ 407 10.4.8 na M na 3706 Repeat request w/ Proxy-Authorization 10.4.8 na ok ok 3709 Repeate request on 408 10.4.9 na ok ok 3726 Send conflict info in body on 409 10.4.10 S S na 3735 Delete references to Request-URI 10.4.11 na S S 1 3755 Send 404 instead of 410 if not perm. 10.4.11 S S na 3758 Repeat request w/ Content-Length on 411 10.4.12 na ok ok 3775 Close connection on 413 10.4.14 ok ok na 3796 Send Retry-After w/ 413 if temporary 10.4.14 S S na 3799 Retry on 413 w/ Retry-After 10.4.14 na ok ok 3801 Send 416 if no Range match 10.4.17 S S na 3826 Send Content-Range w/ 416 10.4.17 S S na 3835 Send Content-Type: multi/byter. w/ 416 10.4.17 MN MN na 3843 Send note in msg body w/ 5xx 10.5 S S na 3860 Display msg body on 5xx 10.5 na na S 3862 Send Retry-After w/ 503 10.5.4 ok ok na 3892 Treat 503 w/o Retry-After as 500 10.5.4 na S S 3893 Send note in msg body w/ 505 10.5.6 S S na 3925 13 Requirements summary for Section 11: Access Authentication ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== 3932 11 Access Authentication HTTP provides several OPTIONAL challenge-response authentication ??? 11 ? ? ? 3933 14 Requirements summary for Section 12: Content Negotiation ... text about variations from the norm ... Notes: Patterson ?Page 13Ù Internet-Draft HTTP requirements summary 20 October 1998 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Negotiate any entity-body 12 ok ok ok 3963 Send Accept-* request headers 12.1 na ok ok 3991 Vary response by any part of request 12.1 ok na na 4024 15 Requirements summary for Section 13: Caching in HTTP ... text about variations from the norm ... Notes: 1 Applies to transparent proxies only. 2 Applies to non-transparent proxies only. 3 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Send most up-to-date response 13.1.1 M M M 4156 Return stale response w/ Warning 13.1.1 ok ok ok 4174 Serve from cache if unconnected 13.1.1 na S S 4183 Send error if unconnected & cannot serv 13.1.1 na M M 4184 Forward stale response w/o added Warn. 13.1.1 na S S 4190 Revalidate response if stale in transit 13.1.1 na SN SN 4192 Display warning if stale w/o Warning 13.1.1 na na ok 4195 Add Warning if response not fresh enuf 13.1.2 na M M 4207 Send Warning for other reasons 13.1.2 ok ok ok 4210 Delete freshness Warnings after reval. 13.1.2 M M M 4217 Delete other Warning after revalidation 13.1.2 MN MN MN 4222 ??? 13.1.2 ? ? ? 4226 ??? 13.1.2 ? ? ? 4226 Warning text in natural language 13.1.2 ok ok na 4238 4240 13.1.2 Warnings headers), and include an OPTIONAL indication of what character set is Multiple Warnings in response 13.1.2 ok ok na 4243 Default cache to non-trans/ineffective 13.1.4 na na SN 4289 Configure cache non-trans/ineffective 13.1.4 na na ok 4291 Inform user if choice overrides server 13.1.4 na na S 4295 Inform continually if ineffective cache 13.1.4 na na S 4305 Send stale responses if not requested 13.1.5 ok ok ok 4314 Send Warning with stale response 13.1.5 M M M 4324 Send stale response if 1st-hand req. 13.1.5 SN SN SN 4329 Specify maximum unvalidated age in req. 13.1.6 na ok ok 4343 Specify minimum remaining age in req. 13.1.6 na ok ok 4345 Specify maximum stage age in req. 13.1.6 na ok ok 4350 Send unexpired cached response 13.2.1 na ok ok 4366 Send expiration in past 13.2.1 ok na na 4388 Validate expired cache entry 13.2.1 S S S 4390 Patterson ?Page 14Ù Internet-Draft HTTP requirements summary 20 October 1998 Send C-C: must-rev to force validation 13.2.1 S na na 4394 Use NTP to synchronize cache clocks 13.2.3 S S S 4430 Interpret Age relative to request 13.2.3 M M M 4484 Send Age with cache entry 13.2.3 M M M 4534 Guess expiration if not explicit 13.2.4 ok ok ok 4580 Send Warning 113 if age > 24 hours 13.2.4 M M M 4581 Guess expiration as part of Last-M int 13.2.4 S S S 4586 Ignore response if cache fresher 13.2.5 na ok ok 4603 Retry req w/ max-age=0 if cache newer 13.2.5 na ok ok 4603 Use freshest response 13.2.5 M M M 4608 Retry req w/ max-age=0 if cache fresher 13.2.6 S S S 4636 Use either response if Date equal 13.2.6 ok ok ok 4649 Retry request if Date equal 13.2.6 ok ok ok 4650 Depend on client choice in same second 13.2.6 MN MN na 4651 Identical validators for strong compar. 13.3.3 M M M 4784 Weak validators for strong compar. 13.3.3 MN MN MN 4784 Identical validators for weak compar. 13.3.3 M M M 4787 Weak validators for weak compar. 13.3.3 ok ok ok 4788 Use weak comparison for simple GET req. 13.3.3 ok ok na 4790 Use strong comparison for other req. 13.3.3 M M na 4791 Use > 60 sec window in date comparison 13.3.3 ok ok ok 4836 Send sub-range GET if Last-Mod strong 13.3.3 na ok ok 4841 Use strong comparison for other req. 13.3.3 M M na 4845 Send entity tag if feasible 13.3.4 S na na 4865 Send weak entity tag if necessary 13.3.4 ok na na 4867 Sent Last-Modified if feasible 13.3.4 S na na 4870 Strong entity tag changes w/ any change 13.3.4 M na na 4877 Weak entity tag changes w/ sign. change 13.3.4 S na na 4878 Use entity tag if provided by server 13.3.4 na M M 4893 Use Last-Mod in simple requests 13.3.4 na S S 4897 Use Last-Mod in sub-range requests 13.3.4 na ok ok 4900 Configure using L-M in sub-range req. 13.3.4 na S S 4901 Use both if both provided 13.3.4 na S S 4904 Send 304 if not consistent w/ conds 13.3.4 MN na na 4911 Use cache entry if not consis w/ conds 13.3.4 na MN na 4917 Store response unless forbidden 13.4 ok ok ok 4955 Use fresh response w/o revalidation 13.4 ok ok ok 4956 Use response after revalidation 13.4 ok ok ok 4957 Violate cache expectation if necessary 13.4 ok ok ok 4960 ??? 13.4 ? ? ? 4974 Store 200/203/206/300/301/410 resp. 13.4 ok ok ok 4988 Store 206 if no range support 13.4 MN MN MN 4991 Use other responses unless controlled 13.4 MN MN MN 4994 Send end-to-end headers to recipient 13.5.1 M M M 5018 Store end-to-end headers in cache 13.5.1 M M M 5020 Use Connection on future hop-by-hops 13.5.1 M M M 5035 Modify end-to-end headers 13.5.2 na SN na 1 5047 Modify C-Loc/C-MD5/ETag/Last-Mod 13.5.2 na MN na 1 5050 Add C-Loc/C-MD5/ETag/Last-Mod 13.5.2 na MN na 1 5051 Modify Expires in response 13.5.2 na MN na 1 5060 Add Expires to response 13.5.2 na ok na 1 5064 Set Expires to Date if adding 13.5.2 na M na 1 5065 Mod/add C-Enc/C-Rng/C-Typ if no-transf. 13.5.2 na MN na 1 5068 Patterson ?Page 15Ù Internet-Draft HTTP requirements summary 20 October 1998 Mod/add C-Enc/C-Rng/C-Typ if non-trans. 13.5.2 na ok na 2 5075 Add Warning: 214 if transforming 13.5.2 na M na 2 5077 Base authentication on other headers 13.5.2 ok ok ok 5083 Preserve entity-length 13.5.2 na M na 1 5087 Change transfer-length 13.5z2 na ok na 1 5089 Combine cache with response on 206 13.5.3 ok ok ok 5106 Delete stored Warning: 1xx 13.5.3 M M M 5115 Retain stored Warning: 2xx 13.5.3 M M M 5117 Replace stored end-to-end headers 13.5.3 M M M 5119 Replace stored end-to-end headers 13.5.3 M M M 5123 Combine sub-range resps. if strong cmp. 13.5.4 ok ok ok 5154 Use most recent resp if not strong cmp. 13.5.4 M M M 5168 Discard other resp if not strong cmp. 13.5.4 M M M 5171 Send Vary when selecting from multiples 13.6 S S na 5182 Use varied cache entry if hdrs not mat. 13.6 MN MN MN 5190 Use varied w/o hdr match w/o checking 13.6 MN MN MN 5209 Send entity tag w/ check request 13.6 S S S 5215 Update cache if same entity tag 13.6 S S S 5227 Send to client if same entity tag 13.6 M M M 5228 Send entity tag if sub-range not complt 13.6 SN SN SN 5231 Send cache entry if response newer 13.6 SN SN SN 5239 Delete cache entry if response newer 13.6 S S S 5240 Secure contents of non-shared cache 13.7 S S S 5248 Store incomplete response 13.8 ok ok ok 5258 Treat incomplete response as partial 13.8 M M M 5259 Combine partial responses 13.8 ok ok ok 5260 Return partial response w/o 206 status 13.8 MN MN MN 5262 Return partial response w/ 200 status 13.8 MN MN MN 5264 Forward 5xx response to client 13.8 ok ok ok 5268 Return cached response if 5xx from srvr 13.8 ok ok ok 5269 Cachable GET/HEAD resp side effects 13.9 SN na na 5287 GET/HEAD have side effects 13.9 ok na na 5288 Treat ? URLs as fresh w/o expiration 13.9 MN MN MN 5296 Send HTTP 1.0 ? responses from cache 13.9 SN SN SN 5298 Invalidate cache on PUT/DELETE/POST 13.10 M M M 5322 Require Location match Host 13.10 M M M 5331 Invalidate cache if request unknown 13.10 S S S 5335 Send non-GET/HEAD req. to server 13.11 M M M 5346 Reply to non-GET/HEAD before response 13.11 MN MN MN 5348 Use new response for current request 13.12 S S S 5364 Store new response 13.12 ok ok ok 5365 Use new response in future if match 13.12 ok ok ok 5366 Follow 13.5.3 rules for caching 13.12 S S S 5369 Keep history list entries current 13.13 na na SN 5382 Display stored history entry if stale 13.13 na na S 5388 16 Requirements summary for Section 14: Header Field Definitions ... text about variations from the norm ... Notes: 1 ... Patterson ?Page 16Ù Internet-Draft HTTP requirements summary 20 October 1998 Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Media parameters on Accept 14.1 na ok ok 5444 Accept-params on Accept 14.1 na ok ok 5447 Interpret Q on Accept correctly 14.1 S S na 5473 Send 406 if none acceptable 14.1 S S na 5479 Q on Accept-Charset 14.2 na ok ok 5544 Send 406 if non acceptable 14.2 S S na 5560 Send 406 if non acceptable 14.3 S S na 5612 Assume client accepts all encodings 14.3 ok ok na 5615 Use identity if available 14.3 S S na 5618 Q on Accept-Language 14.4 na ok ok 5654 Assume client accepts all languages 14.4 S S na 5681 Send Accept-Language if not configurabl 14.4 na MN MN 5693 Send Accept-Ranges: bytes 14.5 ok ok na 5719 Send Range w/o receiving Accept-Ranges 14.5 na ok ok 5723 Send Accept-Ranges: none 14.5 ok ok na 5728 Send Age: 2147483648 on overflow 14.6 M M M 5752 Send Age with result from cache 14.6 M M na 5753 Use 31-bit math on Age values 14.6 S S S 5754 Send allow with 405 response 14.7 M M na 5768 Follow Allow indications 14.7 na S S 5778 Send Allow with PUT request 14.7 na ok ok 5782 Send Allow in response to PUT 14.7 S S na 5785 Modify Allow 14.7 na MN na 5788 Accept credentials for same realm 14.8 S na na 5806 Return cached response against rules 14.8 MN MN MN 5813 Return cached response within s-maxage 14.8 ok ok ok 5824 Revalidate response outside s-maxage 14.8 na M na 5826 Revalidate response w/ s-maxage=0 14.8 na M na 5830 Return cached must-revalidate response 14.8 ok ok ok 5833 Revalidate stale must-revalidate resp. 14.8 M M M 5835 Return public response from cache 14.8 ok ok ok 5840 Obey Cache-Control 14.9 M M M 5846 Pass Cache-Control along 14.9 na M na 5857 Cache private resp in shared cache 14.9.1 MN MN MN 5935 Cache private resp in nonshared cache 14.9.1 ok ok ok 5944 Return C-C: no-cache w/o revalidating 14.9.1 MN MN MN 5952 Return C-C: no-cache w/fldnm w/o reval 14.9.1 ok ok ok 5958 Send C-C: no-cache fields w/o reval 14.9.1 MN MN MN 5960 Send C-C: no-store in req. or response 14.9.1 ok ok ok 5976 Store req./resp if C-C: n-s in request 14.9.1 MN MN MN 5977 Store req./resp if C-C: n-s in resp. 14.9.1 MN MN MN 5979 Store "MUST NOT store" in non-volatile 14.9.1 MN MN MN 5982 Remove "MUST NOT store" from volatile 14.9.1 M M M 5983 Store "MUST NOT store" in history buff. 14.9.1 ok ok ok 5989 Specify expiration time on Expires 14.9.3 ok na na 6010 Specify expiration time via Max-Age 14.9.3 ok na na 6012 Treat Expires <= Date as non-cachable 14.9.3 S S S 6032 Shared cache use stale entry w/o reval. 14.9.3 MN MN MN 6049 Override Expires w/ Max-Age 14.9.3 ok na na 6057 Patterson ?Page 17Ù Internet-Draft HTTP requirements summary 20 October 1998 Override expiration in request 14.9.3 na ok ok 6068 Add Warning: 110 to stale response 14.9.3 M M M 6093 Return stale response w/o revalidation 14.9.3 ok ok ok 6097 Include fld. names on e-e reload req. 14.9.4 MN MN MN 6135 Return cached ent. on e-e reload req. 14.9.4 MN MN na 6136 Use either validator 14.9.4 ok ok ok 6160 Send min-fr./max-stal./max-age w/ no-c 14.9.4 na SN SN 6175 Respond to o-i-c w/ cached ent or 504 14.9.4 S S S 6189 Forward o-i-c cache within group 14.9.4 ok ok ok 6193 Configur to ignore specified expiration 14.9.4 ok ok ok 6197 Send Max-Stale in request 14.9.4 na ok ok 6198 Return C-C: must-reval w/o revalidation 14.9.4 MN MN MN 6203 E-e revalidation for C-C: must-reval. 14.9.4 M M M 6205 Obey Cache-Control: must-revalidte 14.9.4 M M M 6211 Send 504 if cannot reach origin server 14.9.4 M M M 6213 Send C-C: must-reval only when necess. 14.9.4 S S na 6215 Automatically violate C-C: must-reval 14.9.4 MN MN MN 6218 Auto. return unvalidated C-C: must-rev 14.9.4 MN MN MN 6219 Break rules when unconnected 14.9.4 na ok ok 6223 Warn user if breaking rules 14.9.4 na M M 6224 Warn user if breaking rules, all access 14.9.4 na M M 6225 Require confirmation to break rules 14.9.4 na S S 6226 Change hdrs on C-C: no-transform 14.9.5 MN MN MN 6264 Change entity body on C-C: no-transform 14.9.5 MN MN MN 6266 Add informational C-C extensions 14.9.6 ok ok ok 6276 Ignore unrecognized C-C directives 14.9.6 M M M 6313 Forward Connection through proxies 14.10 na MN na 6323 Remove Connection hdrs before forward 14.10 na M na 6332 Send end-to-end hdrs in Connection 14.10 MN MN MN 6341 Consider Connection: Close persistent 14.10 SN SN SN 6351 Send Connection: Close if not pers 14.10 M M M 6354 Remove/ignore Connection hdrs from<=1.0 14.10 M M M 6364 Decode msg body using Content-Encoding 14.11 M M M 6376 Modify content-coding 14.11 na ok na 1 6390 Send Content-Encoding if not identity 14.11 M M M 6395 Send 415 if unacceptable content-coding 14.11 S S na 6399 List content-codings in application ord 14.11 M M M 6403 Encoding parms on other headers 14.11 ok ok ok 6404 Multiple langs on Content-Language 14.12 ok ok ok 6436 Send Content-Language w/ any media type 14.12 ok ok ok 6450 Send transfer length in Content-Length 14.13 S S S 6467 Send Content-Length when known 14.13 S S S 6483 Send other URI in Content-Location 14.14 ok ok ok 6490 Send Content-Location with variant 14.14 S S na 6493 Send Content-Location when accessible 14.14 S S na 6497 Specify C-L URI in future requests 14.14 na ok ok 6509 Generate Content-MD5 14.15 ok na ok 6544 Generate Content-MD5 14.15 na MN na 6547 Check Content-MD5 checksun 14.15 ok ok ok 6549 Remove transfer-encoding before check 14.15 M M M 6555 Multipart Content-MD5 14.15 ok ok ok 6568 Convert LF to CRLF before MD5 14.15 MN MN MN 6577 Use original line break for MD5 14.15 M M M 6579 Patterson ?Page 18Ù Internet-Draft HTTP requirements summary 20 October 1998 Send full entity size in Content-Range 14.16 S S S 6607 Single range in Content-Range 14.16 M M M 6627 Absolute positions in Content-Range 14.16 M M M 6628 Ignore content w/ invalid Content-Range 14.16 M M M 6635 Send range * with 416 response 14.16 S S na 6638 Send range * with 206 response 14.16 MN MN na 6641 Send single range resp as multi range 14.16 MN MN na 6682 Send single resp to m-r req as m-r 14.16 ok ok na 6684 Ask for multi range if can't decode 14.16 na MN MN 6686 Return ranges in request order 14.16 S S na 6690 Ignore entire Range hdr if part bad 14.16 S S na 6694 Send 416 if Range not satisfiable 14.16 S S na 6702 Send RFC 1123 form in Date 14.18 M M M 6737 Send Date on 102-499 response if clock 14.18 M na na 6745 Send Date on 100 and 101 14.18 ok na na 6749 Send Date if no clock available 14.18 MN na na 6757 Follow 14.18.1 rules if no clock avail 14.18 M na na 6759 Add Date if caching msg with none 14.18 M M M 6761 Cache msg w/o Date if no clock 14.18 MN MN MN 6764 Synchronize cache clock w/ reference 14.18 S S S 6766 Send date in req only w/ entity body 14.18 na S S 6769 Send date in req if no clock 14.18 na MN MN 6771 Send date subsequent to msg generation 14.18 SN SN SN 6774 Send date of msg generation 14.18 S S S 6775 Send Expires or Last-Modified w/o clock 14.18.1 MN na na 6792 Send Expires known past w/o clock 14.18.1 ok na na 6794 Compare entities from same resource 14.19 na ok ok 6806 Send error if unrecognized Expect 14.20 M M na 6822 Send 417 if expectation not met 14.20 M M na 6834 Send 417 if unrecognized Expect 14.20 M M na 6846 Send 417 if proxy cannot meet expect. 14.20 na M na 6852 Forward Expect header 14.20 na M na 6855 Follow rules on Expect: 100-continue 14.20.1 M M na 6867 Send 100 or error if Expect: 100-cont 14.20.1 M M na 6867 Forward 100-cont to HTTP 1.1 or unknown 14.20.1 na M na 6874 Forward 100-cont to known HTTP 1.0 14.20.1 na MN na 6876 Send 417 if 100-cont to known HTTP 1.0 14.20.1 na M na 6876 Cache recent HTTP-Versions from servers 14.20.1 na S na 6877 Send 100-cont w/o rcving 100 or 417 14.20.1 na ok ok 6883 Send RFC 1123 date in Expires 14.21 M M M 6911 Treat non-RFC 1123 date as expired 14.21 M M M 6922 Send Expires > 1 year's time 14.21 SN SN na 6752 Send user's email address on From 14.22 na S S 6943 Send From address as RFC 822 mailbox 14.22 na S S 6945 Use From for logging and source ident. 14.22 ok ok na 6954 Use From for access protection 14.22 SN SN na 6955 Robots send From to identify owner 14.22 na S S 6964 Send different host on From 14.22 na ok ok 6968 Send different host on forwarded From 14.22 na S na 6970 Send From w/o user's approval 14.22 na SN SN 6973 Host match original URL 14.23 na M M 6986 Send Host on HTTP 1.1 req. to Internet 14.23 na M M 7002 Add Host before forwarding to Internet 14.23 na M na 7006 Patterson ?Page 19Ù Internet-Draft HTTP requirements summary 20 October 1998 Send 400 if Internet request w/o Host 14.23 M M na 7008 Perform req. if entity tag match or * 14.24 ok ok na 7041 Use strong comparison on If-Match tags 14.24 M M na 7045 Perform req. if no entity tags match/* 14.24 MN MN na 7049 Send 412 if no entity tags match or * 14.24 M M na 7050 Ignore If-Match if resp. not 200/412 14.24 M M na 7057 Perform If-Match: * req. & ent. exists 14.24 S S na 7059 Perform If-Match: * req. & ent. not ex. 14.24 MN MN na 7062 Include If-Match in PUT et al. 14.24 na ok ok 7064 Perform PUT et al. if ent. tag not mat. 14.24 MN MN na 7065 Send 304 if not mod since valid date 14.25 S S na 7119 Perform If-None-Match req. if a match 14.26 MN MN na 7183 Send 304 w/ ETag on If-None-Match match 14.26 S S na 7186 Send 415 if If-None-Match error 14.26 M M na 7189 Perform If-None-Match req. if no match 14.26 ok ok na 7196 Ignore If-Modified-Since if I-N-M 14.26 M M na 7203 Send 304 on I-N-M no match w/ I-M-S 14.26 MN MN na 7204 Perform If-None-Match: * if not exist 14.26 ok ok na 7207 Ignore If-None-Match if not 2xx or 304 14.26 M M na 7213 Perform If-None-Match: * if exists 14.26 MN MN na 7217 Perform If-None-Match: * if not exist 14.26 S S na 7220 Send last-mod date on If-Range 14.27 na ok ok 7255 Send If-Range only with Range 14.27 na S S 7263 Ignore If-Range w/o Range 14.27 M M na 7263 Send 206 w/ range when If-Range matches 14.27 S S na 7268 Send 200 w/ entity when If-Range no mat 14.27 S S na 7270 Perform If-Unmodified-Since if not mod 14.28 S S na 7278 Perform If-Unmodified-Since if modified 14.28 MN MN na 7283 Send 412 if If-Unmodified-Since & mod. 14.28 M M na 7283 Ignore If-Unmod.-Since if not 2xx/412 14.28 S S na 7294 Send Last-Modified > server's msg d/t 14.29 MN na na 7327 Send msg d/t instead of future L-M 14.29 M na na 7330 Obtain last-mod d/t close to Date: d/t 14.29 S na na 7333 Send Last-Modified whenever feasible 14.29 S S na 7339 Send preferred URI on Location 14.30 S S na 7348 Update Max-Forwards on TRACE/OPTIONS 14.31 na M na 7387 Forward TRACE/OPTIONS w/ Max-Forwards:0 14.31 na MN na 7389 Respond to TRACE/OPTIONS w/ M-F: 0 14.31 na M na 7389 Decrement Max-Forwards by 1 before fwd 14.31 na M na 7391 Ignore Max-Forwards on non-TRACE/OPT. 14.31 ok ok na 7394 Require Pragma-consistent behavoir 14.32 ok ok ok 7405 Forward req if Pragma: no-cache 14.32 na S S 7414 Send Cache-Control: n-c w/ Pragma: n-c 14.32 na S S 7418 Pass Pragma with request 14.32 na M na 7419 Ignore Pragma if not relevant 14.32 S S S 7426 Treat P: n-c as Cache-Control: n-c 14.32 S S S 7428 Send Proxy-Authenticate on 407 14.33 na M na 7437 Pass Proxy-Authenticate when forwarding 14.33 na SN na 7451 Relay Proxy-Authorization credentials 14.33 na ok na 7474 One or more byte ranges in Range 14.45.1 ok ok ok 7493 Range last-byte-pos >= first-byte-pos 14.35.1 M M M 7518 Ignore Range if any invalid ranges 14.35.1 M M M 7522 Send 416 if Range not satisfiable 14.35.1 S S na 7548 Patterson ?Page 20Ù Internet-Draft HTTP requirements summary 20 October 1998 Send 206 w/ ranges if Range satisfiable 14.35.1 S S na 7550 Send Range in GET requests 14.35.2 na ok ok 7579 Ignore Range in request 14.35.2 ok ok na 7585 Return requested range only 14.35.2 na S na 7609 Store entire entity in cache 14.35.2 na S na 7610 Send Referer if no referring URI 14.46 na MN MN 7627 Interpret Referer rel. to Request-URI 14.36 S S na 7637 Send fragment in Referer 14.36 na MN MN 7638 Send Retry-After in 3xx response 14.47 ok ok na 7646 Modify Server 14.38 na MN na 7684 Send Via instead of Server 14.38 na S na 7685 Send Connection: TE w/ TE 14.39 na M M 7721 Send Trailer in chunked msg w/ trailer 14.40 S S S 7770 Send headers in trailer w/o Trailer 14.40 SN SN SN 7775 Send headers in trailer w/o TE: chunked 14.40 MN MN na 7779 Send Trans-Enc, Cont-Len, Trailer in t. 14.40 MN MN MN 7783 Send transfer-codings in order applied 14.41 M M M 7813 Send parameters on Transfer-Encoding 14.41 ok ok ok 7814 Send Upgrade in 101 response 14.42 M M na 7826 Send HTTP reply to Updgrade req. first 14.42 M M na 7853 Send Connection: Upgrade w/ Upgrade 14.42 M M M 7857 Send User-Agent in requests 14.43 na na S 7884 Send Vary in cachable resp. w/ neg. 14.44 S S na 7911 Send Vary in non-cachable resp. w/ neg. 14.44 ok ok na 7915 Cache assume same resp w/ Vary info 14.44 ok ok ok 7929 Send Vary: * 14.44 na MN na 7941 Send Via in requests and responses 14.45 na M na 7947 Send pseudonym in Via 14.45 na ok na 7983 Assume default port if none on Via 14.45 ok ok ok 7983 Append Via to end of list 14.45 na M na 7987 Send comments on Via 14.45 na ok na 7991 Remove comments from Via before fwding 14.45 na ok na 7994 Forward names/ports outside firewall 14.45 na SN na 8006 Fwd names/ports outside fw if enabled 14.45 na S na 8007 Send pseudonym outside fw if not enab. 14.45 na S na 8009 Combine Via for privacy reasons 14.45 na ok na 8013 Combine Via under mixed control 14.45 SN SN SN 8023 Combine Via w/ different protocols 14.45 MN MN MN 8025 More than 1 Warning in response 14.46 ok ok ok 8060 Send natural-language Warning warn-text 14.46 S S S 8062 Use avail. knowledge for warn-text lang 14.46 ok ok ok 8064 Encoded non-ISO-8859-1 warn-text 14.46 M M M 8069 Append Warning to list 14.46 S S S 8074 Delete received Warnings 14.46 MN MN MN 8075 Delete added Warnings if validated 14.46 S S S 8077 Add Warnings from validation process 14.46 M M M 8079 Display most important Warnings first 14.46 na na S 8086 Send Warnings in importance order 14.46 S S S 8094 ??? 14.46 ? ? ? 8104 ??? 14.46 ? ? ? 8104 Delete 1xx Warning if validated 14.46 M M M 8108 Generate 1xx Warnings when validating 14.46 ok ok na 8109 Generate 1xx Warnings 14.46 na na MN 8110 Patterson ?Page 21Ù Internet-Draft HTTP requirements summary 20 October 1998 Delete 2xx Warnings if validated 14.46 MN MN MN 8115 Send Warning 110 if stale 14.46 M M M 8121 Send Warning 111 if can't validate 14.46 M M M 8124 Send Warning 112 if disconnected 14.46 S S S 8129 Send Warning 113 if guessed > 24 hrs 14.46 M M M 8133 Send Warning 199 for log or human use 14.46 ok ok ok 8138 Send Warning 199 for automated use 14.46 MN MN MN 8140 Send Warning 214 if entity transformed 14.46 M M M 8144 Send Warning 299 for log or human use 14.46 ok ok ok 8152 Send Warning 299 for automated use 14.46 MN MN MN 8154 Send warn-date=Date on HTTP 1.0 Warning 14.46 M M na 8164 Delete warning-value w/ warn-date!=Date 14.46 M M M 8169 Delete Warning if empty 14.46 M M M 8173 Send WWW-Authenticate in 401 response 14.47 M na na 8178 17 Requirements summary for Section 15: Security Considerations ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Prevent private information leakage 15.1 na na S 8207 Provide control over sensitive info 15.1.2 S S S 8240 Make Server configurable 15.1.2 S na na 8246 Protect info transiting firewall 15.1.2 na S na 8249 Remove or sanitize inside-fw Via 15.1.2 na S na 8252 Send From without user control 15.1.2 na na SN 8264 Allow From configuration 15.1.2 na na M 8265 Send Referer from HTTPS to HTTP 15.1.3 na na SN 8293 Use GET forms for sensitive data 15.1.3 SN na na 8297 Warn user of privacy loss from headers 15.1.4 na na S 8343 Restrict documents to intended areas 15.2 S na na 8349 Prevent unintended file access 15.2 M na na 8352 Disallow ".." for unintended access 15.2 M na na 8357 Protect unintended access to ctl files 15.2 M na na 8361 Use DNS resolver 15.3 na na S 8375 User platform DNS cache if available 15.3 na na S 8379 Honor DNS TTL if caching results 15.3 na na M 8385 Ensure Location & C-Loc in scope 15.4 M na na 8406 18 Requirements summary for Section 16: Acknowledgments None. 19 Requirements summary for Section 17: References None. Patterson ?Page 22Ù Internet-Draft HTTP requirements summary 20 October 1998 20 Requirements summary for Section 18: Authors' Addresses None. 21 Requirements summary for Section 19: Appendices ... text about variations from the norm ... Notes: 1 ... Feature summary Section Srvr Prox Clnt Note Line =============== ======= ==== ==== ==== ==== ===== Parse Status- & Request-Line tolerantly 19.3 S S S 9011 Accept extra space in S-L & R-L 19.3 S S S 9012 Use lowest common denominator charset 19.3 S na S 9020 Assume RFC850-date > 50 years is past 19.3 S S S 9029 Store Expires date as earlier 19.3 ok ok ok 9032 Store Expires date as later 19.3 MN MN MN 9033 Calculate expiration in GMT 19.3 M M M 9036 Use local timezone in age/expir cal/cmp 19.3 MN MN MN 9037 Convert non-GMT d/t conservatively 19.3 M M M 9040 Provide conversion to strict MIME 19.4 na S na 9057 Send MIME-Version 19.4.1 ok ok ok 9072 Convert breaks to CRLF in HTTP->MIME 19.4.2 S S na 9100 Convert dates to HTTP-date 19.4.3 S S na 9123 Fix Content-Encoding in HTTP->MIME 19.4.4 M M na 9133 Remove C-Transfer-Encod in MIME->HTTP 19.4.5 M M na 9144 Add C-T-E in HTTP->MIME if helpful 19.4.5 S S na 9152 Remove Transfer-Encoding in HTTP->MIME 19.4.6 M M na 9160 Respect directory in C-Disp filename 19.5.1 na na SN 9243 Respect only terminal in C-D filename 19.5.1 na na S 9246 Support Host 19.6.1.1 M M M 9326 Send Host in HTTP 1.1 request 19.6.1.1 na M M 9328 Send 400 in no Host in HTTP 1.1 request 19.6.1.1 M M na 9330 Acccept absolute URIs 19.6.1.1 M M na 9333 Wait for body before sending 100 19.6.3 MN na na 9453 22 Requirements summary for Section 20: Full Copyright Statement None. 23 Requirements summary for Section 21: Index None. 24 Security Considerations This document only summarizes the specification in ?2Ù, it does not introduce any new features to HTTP. Therefore, there are no security Patterson ?Page 23Ù Internet-Draft HTTP requirements summary 20 October 1998 considerations particular to the requirements summary itself. 25 Acknowledgments Many thanks to Jeff Mogul at DECWRL for defining the form this document should take in his Internet Draft , from which most of the introductory material was lifted. 26 References 1. R. Braden. Requirements for Internet Hosts -- Communication Layers. RFC 1122, Internet Engineering Task Force, October, 1989. 2. R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. Internet-Draft draft-ietf-http-v11-spec-rev-05, HTTP Working Group, September 11, 1998. 27 Author's address Ross A. Patterson VM Software Division Sterling Software, Inc. 1800 Alexander Bell Drive Reston, VA 20191 USA Email: RossP@SS1.Reston.VMD.Sterling.Com Patterson ?Page 24Ù --------------050304040605090908050102-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 05:31:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00288 for ; Tue, 9 Apr 2002 05:31:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03852; Tue, 9 Apr 2002 05:29:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA03817 for ; Tue, 9 Apr 2002 05:29:56 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00246 for ; Tue, 9 Apr 2002 05:29:52 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g399Trs7002510 for ; Tue, 9 Apr 2002 11:29:53 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 09 11:28:56 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 11:18:36 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4154@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Tue, 9 Apr 2002 11:28:11 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > > --> "Fredrik Lindholm (ERA)" writes: > ... > >So, is your recommendation then that we should register a unique > >a=mikey: > >attribute (and similar for RTSP?) instead of going on with the > >approach in the current draft? How would you like us to proceed? > > I think it depends on how many key management protocols we're > likely to > see. If MIKEY is the only one, then a=mikey: is appropriate. > But, if we > expect to have many key exchange protocols, Steve's concerns > about name > space pollution are important, and an "a=key-mgmt:mikey " > attribute may be better (because it establishes a separate > namespace for > key exchange protocol names). > > However, my main concern is the use of opaque (to SDP) data > in the first > place. I'd be much happier if the key exchange could happen > as part of a > standard offer/answer within SDP, rather than being tunneled. I still vote for the use of the opaque approach. A new reason is due to the re-counting I did of how many parameters we would need to define in SDP (for MIKEY), which is 31 + (#SRTP parameters needed). I.e. this would result in "quite a few" new attributes. The MIKEY message will probably expand with a factor between 2 and 5 (compared to a base64 encoded MIKEY message). Another problem with this would of course be that if a payload would be added (e.g. support a new security protocol) would require a change in SDP (as new parameters might be introduced by the new security protocol). Unless you oppose completely, I would like to go on with the opaque approach. I do not expect that the number of key management protocols that will use the attribute exceeds 4 in the near future (as I only see 3 alternatives right now). So the question is then, whether to use the a=mikey: or to use the a=key-mgmt:mikey . Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 09:00:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03889 for ; Tue, 9 Apr 2002 09:00:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16092; Tue, 9 Apr 2002 08:56:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA16048 for ; Tue, 9 Apr 2002 08:56:36 -0400 (EDT) Received: from epygilab.am (araler.epygilab.am [195.151.94.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03738 for ; Tue, 9 Apr 2002 08:56:30 -0400 (EDT) Received: (apparently) from epygilab.am ([192.168.0.156]) by epygilab.am with Microsoft SMTPSVC(5.5.1877.197.19); Tue, 9 Apr 2002 16:56:24 +0400 Received: from armenm [192.168.0.167] by epygilab.am [192.168.0.156] with SMTP (MDaemon.PRO.v5.0.1.R) for ; Tue, 09 Apr 2002 17:55:21 +0500 Message-ID: <001c01c1dfc6$a3702940$a700a8c0@epygi.loc> From: "Armen Martirosyan" To: Date: Tue, 9 Apr 2002 18:01:17 +0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C1DFF0.8C2785B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-MDRemoteIP: 192.168.0.167 X-Return-Path: Armen.Martirosyan@epygilab.am X-MDaemon-Deliver-To: mmusic@ietf.org Subject: [MMUSIC] Hello Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C1DFF0.8C2785B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello to everyone in mmusic@ietf.org In my first post I have a question about fax supporting in SIP. I`m downloaded in ITU T38 Recommendation including ANNEX D (for SIP) = and based that two drafts=20 draft-ietf-sipping-call-flows-00.txt draft-mule-sip-t38callflows-02.txt. =20 I don`t know are there other documentations , recommendations in this = area? If somewone know please send me about this problem , and if it is = possible list of documentations or where I can find its? Thanks in advance. Best regards. =20 Armen Martirosyan. ------=_NextPart_000_0019_01C1DFF0.8C2785B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello to everyone in mmusic@ietf.org
 
In my first post I have a question = about fax=20 supporting in SIP.
 
I`m downloaded in  ITU = T38  Recommendation including ANNEX D (for SIP) and=20 based that two drafts =
   =20 draft-ietf-sipping-call-flows-00.txt
   =20 draft-mule-sip-t38callflows-02.txt.
 
I don`t know are there other documentations = , recommendations  in=20 this area?
If somewone know  please send me about this problem , and if = it =20 is possible list of documentations
or where I can find its?
 
Thanks in advance.
Best regards.
 
Armen Martirosyan.
 
------=_NextPart_000_0019_01C1DFF0.8C2785B0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 09:12:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04217 for ; Tue, 9 Apr 2002 09:12:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17299; Tue, 9 Apr 2002 09:08:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA17270 for ; Tue, 9 Apr 2002 09:08:52 -0400 (EDT) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04063 for ; Tue, 9 Apr 2002 09:08:47 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message Subject: RE: [MMUSIC] Hello MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 9 Apr 2002 09:08:17 -0400 Message-ID: Thread-Topic: [MMUSIC] Hello Thread-Index: AcHfxqsDrXWiP1ZLRT+yBXrtbD5BmgAAHpVQ From: "David Yon" To: "Armen Martirosyan" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id JAA17271 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Last I checked, Annex D included support for listing TCP as a transport for T.38. The mechanism is underspecified however, and the draft-ietf-mmusic-comedia-01.txt draft (soon to be comedia-02) should provide a framework that would allow SIP signaling of T.38 with TCP (and for those concerned with privacy: TLS) as the transport. -----Original Message----- From: Armen Martirosyan [mailto:Armen.Martirosyan@epygilab.am] Sent: Tuesday, April 09, 2002 9:01 AM To: mmusic@ietf.org Subject: [MMUSIC] Hello Hello to everyone in mmusic@ietf.org In my first post I have a question about fax supporting in SIP. I`m downloaded in ITU T38 Recommendation including ANNEX D (for SIP) and based that two drafts draft-ietf-sipping-call-flows-00.txt draft-mule-sip-t38callflows-02.txt. I don`t know are there other documentations , recommendations in this area? If somewone know please send me about this problem , and if it is possible list of documentations or where I can find its? Thanks in advance. Best regards. Armen Martirosyan. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 09:55:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05592 for ; Tue, 9 Apr 2002 09:55:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20221; Tue, 9 Apr 2002 09:51:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20168 for ; Tue, 9 Apr 2002 09:51:50 -0400 (EDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05392; Tue, 9 Apr 2002 09:51:48 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g39DpEg14362; Tue, 9 Apr 2002 09:51:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 9 Apr 2002 09:51:14 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A2A2@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'megaco@ietf.org'" , "'mmusic@ietf.org'" Date: Tue, 9 Apr 2002 09:51:10 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org I have recycled this document at last. Material relating to Nx64 kbit/s or multilink operation has been stripped out, and material relating to H.320 and H.324 sessions has been modified to conform to the latest views of how Megaco operates. I forgot to put in the MIME registrations for audio/PCMU, audio/PCMA, audio/G726xx, and application/octet-stream all over TDM transport, but I'll do that on the next pass. I sent a copy to Jim Renkel, who had urged that requirements for CAS-signalled TDM be taken into account when I first presented this to MMUSIC. I have no idea what additional requirements he has in mind, but I'll see. In the meantime, does anyone else have comments? We need this for NAS operation. -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, April 09, 2002 8:41 AM Subject: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Conventions for the use of the Session Description Protocol (SDP)for Digital Circuit Connections Author(s) : T. Taylor Filename : draft-taylor-mmusic-sdp-tdm-01.txt Pages : 14 Date : 08-Apr-02 This document describes conventions for using the Session Description Protocol (SDP) for controlling digital circuits. These conventions describe - circuit addressing conventions for use on the SDP 'c=' line - content of the 'm=' line(s) for digital circuits - attributes to convey the parameters contained within the Bearer Capability, Low Layer Compatibility, and High Layer Compatibility Information Elements of ITU-T Recommendation Q.931. These conventions have been defined for use in media gateway control, particularly in support of NAS operation, but may also be used by IP-based call signalling schemes (SIP, BICC) to control media exchange over digital circuits. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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. ----- To: Subject: Date: Tue, 9 Apr 2002 09:51:14 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) begin 600 ATT64470 M0V]N=&5N="UT>7!E.B!M97-S86=E+V5X=&5R;F%L+6)O9'D[#0H)86-C97-S M+71Y<&4](FUA:6PM'0O<&QA:6X-"D-O;G1E;G0M240Z M"3PR,#`R,#0P.#$R,C8U,"Y)+41`:65T9BYO appropriate to have a section explaining how comedia is used with > SIP (i.e. offer/answer), RTSP, MEGACO and perhaps SAP. > In SIP I believe it is equally relevant to both offer/answer and three-way handshake (INVITE/OK/ACK). I made an attempt to describe the semantics in protocol-independant manner to reduce the dependencies of this draft, and I think that the language describes the scenarios correctly. The two sections where this is most visible are the "Optimizing direction:both" and "Connection and Listener Lifetime Considerations". It would be helpful if those that are more familiar with the upper-level protocols (especially RSTP and MEGACO) would check the language to make sure that there are not impedance mismatches introduced to those protocols. > - Section 2.6 says that you MUST NOT send media on a passive > port until > a packet has been received. Does this include not sending RTCP? > I got that language from Rohan Mahy. Rohan? Clarification? > - In section 3, how is the source address useful given that > it can't be > trusted? More explanation of how it can be used is probably needed. > There is a big "NOTE:" section in "Source-Address Considerations" that covers this. What am I missing? > - Section 4.1: the time window is the t= line? > The t= line is not directly referenced since I believe the endpoint's time window semantics can be derived from other sources (SIP Session Timer comes to mind). > - The possible race when both parties select diraction:both > concerns me, > but I'm not sure I can see a better alternative (unless > there's some > trick to make one side win deterministically, for example > the lowest > IP address wins). > Short of mechanisms that involve additional handshaking by the upper layer protocol, I saw no way to completely eliminate the race. Keep in mind that the two-connection condition is not fatal (nor even that cumbersome, since existing RTP/UDP implementations already have to track different transport information for inbound vs outbound media), and that the suggested mechanism should sufficiently reduce the likelihood of the race that excess resource utilization should be minimized. > Editorial comments: > > - The section numbering needs to start with the introduction > as section 1. Done. > - The introduction and motivation sections could easily be > combined. Add a > couple of sentances to the end of the combined section > saying that "this > memo defines two new protocol identifies, TCP and TLS, > along with the > syntax and semantics of the a=direction attribute". Done. > - Move the terminology section after the combined > introduction/motivation Done. > - A couple of instances of non-ASCII characters need to be fixed. Will hand check that in the final submission, MS Word seems to creep those in despite my best efforts. > - A couple of places say "the a= line" but mean "the > a=direction:" line > (e.g. end of section 2.2, second paragraph of section 2.3, ...) > Done. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 12:57:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12042 for ; Tue, 9 Apr 2002 12:57:25 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03484; Tue, 9 Apr 2002 12:44:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03439 for ; Tue, 9 Apr 2002 12:44:00 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11724; Tue, 9 Apr 2002 12:43:58 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g39GhOON019888; Tue, 9 Apr 2002 09:43:24 -0700 (PDT) Received: from RKUMARW2K (sjc-vpn1-89.cisco.com [10.21.96.89]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA07876; Tue, 9 Apr 2002 09:43:23 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Christian Groves" Cc: "Dan Firac" , "Colin Perkins" , , Subject: RE: [AVT] RE: [MMUSIC] Silence Suppression Attribute Date: Tue, 9 Apr 2002 09:43:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CB26115.48BFB6D2@ericsson.com.au> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit G'Day Christian, You are right. However, the need to optionally indicate ECAN remains. In SIP offer/answer, this will be through SDP, right? - since there is no other mechanism. The point I'm making is that ECAN is a valid parameter to indicate at call/connection/session establishment time. Dan's point that this is not codec-related is well-taken; perhaps, there is a need for a media level "a=ecan..." for the VoIP. This exists for VoATM in rfc3108. Rajesh > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Christian Groves > Sent: Monday, April 08, 2002 8:34 PM > To: rkumar@cisco.com > Cc: Dan Firac; Colin Perkins; mmusic@ietf.org; avt@ietf.org > Subject: Re: [AVT] RE: [MMUSIC] Silence Suppression Attribute > > > Hello Rajesh, > > One of your statements confuses me: > ..snip.. > > However, let us look at ECAN further. H.248 and MGCP do allow ECAN to be > > indicated per connection, why should SIP offer/answer be precluded from > > doing so? Further, H.248 would use SDP/tags for the MGC to > enable/disable > > ECAN per connection, since it does not have the equivalent of the local > > connection option in MGCP. > > > H.248/Megaco has a package property to indicate Echo Cancellation. This is > listed in the Local Control descriptor not under local and > remote. So for H.248 > the MGC does not use SDP for Echo cancellation. > > Regards, Christian > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 13:05:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12233 for ; Tue, 9 Apr 2002 13:05:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04169; Tue, 9 Apr 2002 12:57:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04139 for ; Tue, 9 Apr 2002 12:57:42 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12059 for ; Tue, 9 Apr 2002 12:57:36 -0400 (EDT) Received: from imop.cisco.com (IDENT:mirapoint@imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g39Gv6MY013136; Tue, 9 Apr 2002 09:57:06 -0700 (PDT) Received: from localhost (ssh-sjc-1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with ESMTP id ACV23720; Tue, 9 Apr 2002 09:57:05 -0700 (PDT) Date: Tue, 9 Apr 2002 09:54:20 -0700 (Pacific Daylight Time) From: Rohan Mahy To: David Yon cc: Colin Perkins , Subject: RE: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Message-ID: X-X-Sender: rmahy@imop.cisco.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi David, A few minor comments inline. On Tue, 9 Apr 2002, David Yon wrote: > Thanks Colin for looking over the draft in such detail. Comments inline > below. > > > > > - The Protocol Identifiers section may want to point to the > > discussion of > > m= in SDP, which specifies that the identifiers are MIME > > subtypes for > > audio/video/application media types. This is implicit in > > the examples, > > and explicit in SDP, but not noted in this draft. > > > > I will add the following text to the "Protocol Identifiers" section > (directly before the "TCP" section): > > The m= line in [SDP] is where an endpoint specifies the protocol > > used for the media in the session. See the "Media > Announcements" > section of [SDP] for a discussion on protocol identifiers > > > > - Section 2.2 ("Semantics of direction:active") could go with an SDP > > fragment, showing exactly where the source and destination address > > and port are specified (i.e. an SDP fragment including c=, m= and > > a=direction lines). > > > > Added. > > > > - How specific is this to SDP used with offer/answer? It's probably > > appropriate to have a section explaining how comedia is used with > > SIP (i.e. offer/answer), RTSP, MEGACO and perhaps SAP. > > > > In SIP I believe it is equally relevant to both offer/answer and > three-way handshake (INVITE/OK/ACK). I made an attempt to describe the > semantics in protocol-independant manner to reduce the dependencies of > this draft, and I think that the language describes the scenarios > correctly. The two sections where this is most visible are the > "Optimizing direction:both" and "Connection and Listener Lifetime > Considerations". It would be helpful if those that are more familiar > with the upper-level protocols (especially RSTP and MEGACO) would check > the language to make sure that there are not impedance mismatches > introduced to those protocols. The SIP three-way handshake is now decoupled from the offer/answer model. If you want an offer/answer/counter-offer in SIP you actually implement that as a pair of offer/answer exchanges. I couldn't find anything in the draft that was incompatible with the SIP usage. > > - Section 2.6 says that you MUST NOT send media on a passive > > port until > > a packet has been received. Does this include not sending RTCP? > > > > I got that language from Rohan Mahy. Rohan? Clarification? Short answer is: the passive peer can't send RTP until it has recieved a packet of RTP on the RTP port, and can't send RTCP until it has received a packet of RTCP on the RTCP port. You can't (and MUST NOT) send RTP, RTCP, UDP, TCP, etc... media from a passive port until a packet has arrived to that port from (presumably) the active peer. The reason is simple--you don't know the address/port of your peer until your recieve that first packet. hope this helps. thanks, -rohan > > - In section 3, how is the source address useful given that > > it can't be > > trusted? More explanation of how it can be used is probably needed. > > > > There is a big "NOTE:" section in "Source-Address Considerations" that > covers this. What am I missing? > > > > - Section 4.1: the time window is the t= line? > > > > The t= line is not directly referenced since I believe the endpoint's > time window semantics can be derived from other sources (SIP Session > Timer comes to mind). > > > > - The possible race when both parties select diraction:both > > concerns me, > > but I'm not sure I can see a better alternative (unless > > there's some > > trick to make one side win deterministically, for example > > the lowest > > IP address wins). > > > > Short of mechanisms that involve additional handshaking by the upper > layer protocol, I saw no way to completely eliminate the race. Keep in > mind that the two-connection condition is not fatal (nor even that > cumbersome, since existing RTP/UDP implementations already have to track > different transport information for inbound vs outbound media), and that > the suggested mechanism should sufficiently reduce the likelihood of the > race that excess resource utilization should be minimized. > > > > Editorial comments: > > > > - The section numbering needs to start with the introduction > > as section 1. > > Done. > > > - The introduction and motivation sections could easily be > > combined. Add a > > couple of sentances to the end of the combined section > > saying that "this > > memo defines two new protocol identifies, TCP and TLS, > > along with the > > syntax and semantics of the a=direction attribute". > > Done. > > > - Move the terminology section after the combined > > introduction/motivation > > Done. > > > - A couple of instances of non-ASCII characters need to be fixed. > > Will hand check that in the final submission, MS Word seems to creep > those in despite my best efforts. > > > - A couple of places say "the a= line" but mean "the > > a=direction:" line > > (e.g. end of section 2.2, second paragraph of section 2.3, ...) > > > Done. > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 9 20:20:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26302 for ; Tue, 9 Apr 2002 20:20:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00325; Tue, 9 Apr 2002 20:09:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00290 for ; Tue, 9 Apr 2002 20:09:48 -0400 (EDT) Received: from uni01mr.unity.ncsu.edu (uni01mr.unity.ncsu.edu [152.1.1.164]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26175 for ; Tue, 9 Apr 2002 20:09:46 -0400 (EDT) Received: from unity.ncsu.edu (wi400-20-54.eos.ncsu.edu [152.1.20.54]) by uni01mr.unity.ncsu.edu (8.11.6/8.11.6/N.20020313.01) with ESMTP id g3A09mt22141 for ; Tue, 9 Apr 2002 20:09:48 -0400 (EDT) Message-ID: <3CB382CB.FC5A00D@unity.ncsu.edu> Date: Tue, 09 Apr 2002 20:09:47 -0400 From: Prashant Gupta Organization: NC State University X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org References: <200204091600.MAA00451@optimus.ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Query regarding a=type: attribute Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi, From draft-ietf-mmusic-sdp-new-06 pg 26, a=type:moderated attribute should start the media tools in a "mute" mode. Does this imply that the a=inactive attribute is implied by the above for each of the media lines? A related query is that, what exactly do SDP attributes for media lines describe? Do they indicate the current state of the media stream or do they indicate the nature of the media stream. To clarify a little, I am wondering if there is a need for an "update" in SDP attributes, when say, a particular conference participant is not given the right to address the conference by a moderator (this doesnt change the basic nature of the media being sendrecv, but is just temporarily not giving the user permissions to send/recv this stream). Regards, Prashant Gupta. Graduate Student NC State University, Raleigh, NC. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 10 10:12:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20214 for ; Wed, 10 Apr 2002 10:12:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23856; Wed, 10 Apr 2002 10:01:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA23802 for ; Wed, 10 Apr 2002 10:01:16 -0400 (EDT) Received: from vs.informatik.uni-ulm.de (vs.informatik.uni-ulm.de [134.60.77.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19740 for ; Wed, 10 Apr 2002 10:01:10 -0400 (EDT) Received: from lisa (lisa.informatik.uni-ulm.de [134.60.77.205]) by vs.informatik.uni-ulm.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with SMTP id g3AE2Qg17668; Wed, 10 Apr 2002 16:02:29 +0200 X-Authentication-Warning: vs.informatik.uni-ulm.de: Host lisa.informatik.uni-ulm.de [134.60.77.205] claimed to be lisa Message-ID: <020801c1e098$48d51720$01000001@lisa> From: "Andreas Kassler" To: , References: <3CADC43C.8693B411@alcatel.be> Subject: [MMUSIC] SDP(ng)&QoS Date: Wed, 10 Apr 2002 16:01:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi, also for me it is clear, that QoS extensions to SDPng are urgently needed. However, it seems to me that discussion about QoS and capability negotiation needs some coordination and extension. There are several drafts floating around in MMUSIC and other areas that address QoS in the one or other field. Also, there seems to be a misunderstanding, what QoS means in which context. For example, some drafts consider QoS negotiation only for network/transport layer parameters (e.g. draft-bos-mmusic-sdpng-qos-00.txt). Other drafts (e.g. draft-guenkova-mmusic-e2enp-sdpng-00.txt) focus on application level QoS and let other areas (e.g. NSIS, manyfolks) concentrate on the signalling of network/transport layer QoS. Whereas the inclusion of QoS parameters at network/transport layer seems to be a first step towards bringing QoS into SDPng (it has been a requirement for the SDPng design), there is significant more work to do. For example there has been a number of drafts (e.g. draft-levin-sip-for-video-XX.txt) that have identified the need for the following topics that deal with end-to-end QoS at application level (inline with the proposals/requirements in draft-guenkova-mmusic-e2enp-sdpng-00.txt): - Ultimate goal should be to come to a solution to enable SIP/SDP/SDPng/RTP/RTCP systems to provide real-time multimedia services across global networks with quality video and audio that delivers a satisfying and predictable end user experience. - We should think about how SDPng can participate best to solve the puzzle! - We should be aware of the fact that during a session's lifetime, the characteristics/capabilities of the endterminal may be changing dynamically both as a result of network conditions, as a result of mobility (different access network due to hand-off in multihomed terminals) and as part of software reconfiguration (e.g. codec download) and of terminal resource usage (e.g. starting of local applications). - Another point to consider is that typically a multimedia application has to maintain many audio and video streams in parallel. There are QoS requirements for a given stream (e.g. a certain frame rate, frame size and visual quality), but there are also QoS requirements between the stream (inter-stream correlation/synchronization). These have to be negotiated as well. -There has to be a mechanism to reference a given stream and change its QoS characteristics, once the streaming has already started. This has to be achieved without changing the codec. For example, if a hand-over occurred and the network/transport QoS can no longer be maintained, the user may want to switch from 20 fps to 15 fps for the video stream. Referencing a stream within a multimedia session also enables the negotiation of inter-stream QoS requirements. -There has to be a mechanism to negotiate capabilities independently from application level QoS. For video, certain codecs may achieve the same application level QoS but the resource requirements may differ. - There has to be a mechanism to negotiate a set of valid application QoS configurations, e.g. an adaptation path, that are enforced in case a QoS violation occurred. For example start at (20 fps,CIF), switch to (15 fps,CIF), (10 fps,CIF), (10 fps,QCIF), (5 fps,QCIF),... This has to be achieved independently of any codec decisions to provide mechanisms for dynamic codec download. To minimize signalling traffic, there should be mechanisms to reference such points within an Adaptation Path. -There has to be a mechanism to specify a bandwidth range or a set of Traffic parameters to a given codec. Video codecs can operate at a broad range of target bandwidth sets. For each Traffic parameter set, a number of alternative sensitivity (e.g. delay, jitter) information should be supported. Also, video may complicate things as for a given set of traffic parameters, many combinations of application QoS parameters exist. For example, there are situations where (15 fps,CIF) may result in the same amount of traffic as (30 fps,QCIF). When considering visual quality as another application level QoS parameter, there are many more combinations possible. -There should not be any restriction about what architecture to use for network/transport resource signalling/provision at session initiation time. Additionally, SIP signaling (together with SDPng content) may take in general a different path than data. -it is not desirable that intermediate nodes remove parts of the original session description in mobile environments. Consider the following example: Node A supports MPEG4 at 768 kBit/s and at 384 kBit/s. Let us assume that the terminal is multihomed and at the moment uses UMTS and lets assume that 768 kBit/s are not supported at the moment. If an intermediate node changes the session description by removing the 768 kBit/s entry the peer B receiving this information would have no knowledge that in principle Node A could use 768 kBit/s based on Node As capabilities. If Node A enters the building and dynamically switches to an inhouse W-LAN, the 768 kBit/s would be no problem on an end-to-end basis, but the peer B does not know it. There are many more issues to consider when talking about real end-to-end QoS. Currently, NSIS is targeting at a signalling protocol for network/transport QoS. However, that is only half the game. It is worth to look at negotiating and maintaining end-to-end QoS at the application layer, that also has to include management of local resources (which is out of scope of the MMUSIC WG). I believe that extensions to SDPng together with SIP are a very good solution to provide mechanisms to negotiate capabilities and end-to-end QoS at application layer and coordinate this with signalling for network/transport QoS (e.g. NSIS or IntServ or whatever) even in a wireless and mobile environment. However, there are significantly more issues to that than introducing only traffic/sensitivity information in a session description. It was the intention of draft-guenkova-mmusic-e2enp-sdpng-00.txt to first fully understand requirements for SDPng to support QoS at application layer in a mobile environment, before we start to draft some solutions. However, in my opinion this discussion needs also some coordination from the WG chairs on how to proceed. For example to determine whether SDPng shall focus on application level QoS negotiation (frame size, visual quality,...), and/or on network/transport level QoS negotiation, and/or to negotiate *and coordinate* both application and transport/network level QoS, in order to provide a uniform QoS solution. Regards, Andreas _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 10 21:00:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06286 for ; Wed, 10 Apr 2002 21:00:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA01027; Wed, 10 Apr 2002 20:54:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00993 for ; Wed, 10 Apr 2002 20:54:50 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06263 for ; Wed, 10 Apr 2002 20:54:44 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g3B0sFKR001012 for ; Wed, 10 Apr 2002 17:54:15 -0700 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g3B0sDxu032646 for ; Wed, 10 Apr 2002 17:54:13 -0700 Date: Wed, 10 Apr 2002 17:57:09 -0700 (Pacific Daylight Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: Minutes, April 3 telecon Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Below are the minutes from the RTSP telecon on April 3. Also available online: http://rtsp.org/2002/telecon/minutes03Apr.html Rob RtspTcMinutes03Apr2002 ------------------------------------------------------------------------ 1. Agenda 2. Attendees 3. Discussion 1. Issue: SETUP and TEARDOWN in "play" state 2. ISSUE: End of media state 3. Issue: Resume point at end of range 1 Agenda * Agenda: http://rtsp.org/2002/telecon/agenda03Apr.html 2 Attendees Attendees (phone): * Magnus Westerlund (MW) * Anders Klemets (AK) * Anne Jones (AJ) * Milko Boic (MB) * David Walker (DW) * Rob Lanphier (RL) * Jonathan Sergent (JS) * Sean Sheedy (SS) * Aravind Narasimhan (AN) * Tom Marshall (TM) * Thomas Zeng (TZ) Attendees (IRC): * Virago (?) 3 Discussion 3.1 Issue: SETUP and TEARDOWN in "play" state Issue: Should SETUP and TEARDOWN be allowed in "play" state in the RTSP state machine? * JS: Our decision with PLAY and PAUSE would point to an answer of "no" * MW: this would be new functionality * RL: uses lots of ports * JS: doesn't increase the maximum number of ports * MB: what about MPEG-4 * JS: my understanding with BIFS is that it arrives in a single stream * JS: bad to have two mechanisms for same thing * MB: slightly different features * JS: lots of extra func in 2326, need to trim * RL: interest in mute/unmute functionality * JS: yes * AN: qustion of client functionality * TM: original spec includes functionality * MW: mute method should be optional * MW: regardless of which way we go * AK: I always thought that setup and teardown were always allowed * MW: old spec was unclear. should be marked as new feature with feature tag * MW: we should still allow chaging of transport parameters using SETUP during PLAY * AK: we implement setup and teardown during PLAY * JS: interop is tough if we have lots of different options * MB: this also allows people to implement just the core functionality * JS: spec doesn't really define this new functionality * AN: it does specify TEARDOWN * JS: should stay as extension * RESOLUTION: no resolution. Take to list. Should specification allow SETUP on existing stream? Should specification allow SETUP of a new stream? * ACTION ITEM: AN to drive discussion 3.2 ISSUE: End of media state ISSUE: When a media reaches the end of a media should the resume point be set to begining of clip, although it will remain in playing state? * RL: I think that it should stay at the end. Other opinions? * SS: doesn't the current spec imply that the media is reset? * JS: unclear in current RFC....most do the same thing * AN: not necessarily...if a range is sent, everything is reset * JS: we may break if we change things * SS: we go back to the beginning * AN: our server stops at the end * JS: are there clients that take advantage of either? * MW: auto rewind will fail anyway * MW: ..because of new PAUSE req. * JS: not necessarily * MW: we need to have no automatic state transition * JS: Are there clients that break? * AN: Apple client normally sends PAUSE at the end * TZ: when we reach the end of the clip, we send notification to the player * TZ: "END_OF_CLIP" method sent to client * AK: we also send end of clip in SET_PARAMETER * SS: we send notification as well * JS: should be draft * RL: not sure....the state should be client driven * MW: would like to force client to send PAUSE at end...that's the notification * JS: need to not break current client * RL: resolution? When end of media is reached, server stays in "play" state. * JS: should be "invalid range" if PAUSE/PLAY (no range) issued * RL: resolution? server stays in play state at "error" time at end of clip. subsequent PLAY request needs to follow pause, and must have new range * /resolution was made, but subsequently reversed. See next resolution/ 3.3 Issue: Resume point at end of range ISSUE: When a media reaches the end of the specified range(s) should the resume point be set to 0.0 or the end of the range? * ??: revise previous resolution * RESOLUTION (for this and last): server issues Range: in PAUSE request which is at the end of the clip. A subsequent PLAY with no range will be identical to PLAY request with the Range returned in the in PAUSE _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 05:02:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22572 for ; Thu, 11 Apr 2002 05:02:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04050; Thu, 11 Apr 2002 04:52:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA04017 for ; Thu, 11 Apr 2002 04:52:09 -0400 (EDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22478 for ; Thu, 11 Apr 2002 04:52:05 -0400 (EDT) From: suresh.leroy@alcatel.be Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g3B8pbu16610 for ; Thu, 11 Apr 2002 10:51:37 +0200 (MET DST) Received: from alcatel.be ([138.203.33.40]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002041110513559:416 ; Thu, 11 Apr 2002 10:51:35 +0200 Message-ID: <3CB54E96.258DB1C8@alcatel.be> Date: Thu, 11 Apr 2002 10:51:34 +0200 Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/11/2002 10:51:35, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/11/2002 10:51:37, Serialize complete at 04/11/2002 10:51:37 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MMUSIC] SDG ALG behaviour Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi all, I was wondering if there exists something like a standard or recommended behaviour for SDP ALGs (application level gateways). If for instance a dual stack host provides two IP addresses (IPv4 & IPv6) in his SDP and at some point in the network SIP level interworking is needed: 1) Does the SDP interworking have to take place at the same location? The SIP interworking location might not always be aware if the IP version of the end-host thereby maybe introducing an unnecessary interworking at the media level. 2) Will the SDP ALGs be smart enough to see that interworking at SDP level is not needed as two IP addresses are provided? Or is the default behaviour that, if for instance a NAT-PT is needed for SIP automatically also one for the RTP streams will be inserted. Regards, Suresh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 12:03:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04400 for ; Thu, 11 Apr 2002 12:03:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24897; Thu, 11 Apr 2002 11:53:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24852 for ; Thu, 11 Apr 2002 11:52:57 -0400 (EDT) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04015 for ; Thu, 11 Apr 2002 11:52:52 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message Subject: RE: [MMUSIC] Prelim copy of comedia-02 available MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 11 Apr 2002 11:52:21 -0400 Message-ID: Thread-Topic: [MMUSIC] Prelim copy of comedia-02 available Thread-Index: AcHf55XvmZwDS1W6Q4igO+RnT+6n/ABiSnyA From: "David Yon" To: "Rohan Mahy" Cc: "Colin Perkins" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA24853 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit > Short answer is: the passive peer can't send RTP until it has > recieved a > packet of RTP on the RTP port, and can't send RTCP until it > has received a > packet of RTCP on the RTCP port. > > You can't (and MUST NOT) send RTP, RTCP, UDP, TCP, etc... > media from a > passive port until a packet has arrived to that port from > (presumably) the > active peer. The reason is simple--you don't know the address/port of > your peer until your recieve that first packet. > Ok, unless there are objections, I'm changing the sentence to read: Endpoints that specify direction:passive MUST NOT send any media, including control packets such as RTCP, from their passive ports until they receive a packet on these ports and record the source address and port of the sender. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 17:07:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15017 for ; Thu, 11 Apr 2002 17:07:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13386; Thu, 11 Apr 2002 17:03:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13354 for ; Thu, 11 Apr 2002 17:03:30 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14912 for ; Thu, 11 Apr 2002 17:03:26 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3BL39P03891; Thu, 11 Apr 2002 17:03:09 -0400 Message-Id: <200204112103.g3BL39P03891@chiron.nge.isi.edu> To: rkumar@cisco.com cc: "Dan Firac" , mmusic@ietf.org Subject: Re: [MMUSIC] Silence Suppression Attribute In-Reply-To: Your message of "Sun, 07 Apr 2002 22:06:00 PDT." Date: Thu, 11 Apr 2002 17:03:09 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Rajesh, I think this is a good start, but it needs a definition of the type of parameter that can be included in the new attribute (and, depending on the definition, a more appropriate name for the attribute). You have two examples: one affects the operation of the playout buffer, the other affects part of the terminal outside the realm of RTP or the packet network. I'm not sure it's appropriate to have such different parameters signalled in a single attribute, but without a definition of the attribute, it's difficult to tell what is appropriate. I also think the discussion of RFC 2198 should not be in this draft. Colin --> "Rajesh Kumar" writes: >Please comment on >http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gfmtp-00.txt >. This might fit the "generic format parameters" Colin mentioned. > >Rajesh Kumar >Cisco Systems > >> -----Original Message----- >> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of >> Colin Perkins >> Sent: Friday, April 05, 2002 9:45 AM >> To: Dan Firac >> Cc: mmusic@ietf.org >> Subject: Re: [MMUSIC] Silence Suppression Attribute >> >> >> Dan, >> >> I think Steve's email mostly answers this. If the codec has parameters to >> determine how the silence suppression works, these need to be specified as >> part of the payload format. >> >> For just signalling the preference that that suppression not be performed >> (and clearly this can only be a preference), a "generic format parameters" >> is probably the best way to proceed, rather than a specific attribute for >> silence suppression. >> >> Colin >> >> >> --> "Dan Firac" writes: >> >It's about user preferences. >> > >> >Scenario: >> >If the user prefers to DISABLE Silence Suppresion in order to >> acheive higher >> >audio quality, then the SDP composed by its phone should express >> this wish. >> > >> >Further pros: >> >1) Silence suppression it's a PARAMETER for many codecs, and >> >I think it should be present in SDP offers/answers. >> >2) When the remote end is not well tuned (ex: volumes), the VAD on the >> >remote end may >> >brutally cut the speech, so our local user will not know/feel if >> there were >> >loses or >> >the remote user stopped speaking. >> >3) The same thing happens when the local user has G723 without >> AnnexA (VAD), >> >G729 without AnnexB, and would want to force the remote end to use >> >a codec without silence suppression. >> > >> >Points 2) and 3) are about gaining some quality. >> > >> >You are right, RTP assumes silence suppression and all the scenarios >> >(including the above scenarios) are working without negotiating Silence >> >Suppression. >> >But is the obtained quality the best quality that can be acheived????? >> > >> >I think the user should decide it and the SDP should offer him >> >a mechanism (at least, optional) to express his preferences. >> > >> >Best regards, >> >Dan Firac, >> >Software Engineer, >> >RedlineCommunications, >> >Romania. >> > >> > >> >----- Original Message ----- >> >From: "Colin Perkins" >> >To: "Dan Firac" >> >Cc: "Tom-PT Taylor" ; >> >Sent: Thursday, April 04, 2002 2:22 AM >> >Subject: Re: [MMUSIC] Silence Suppression Attribute >> > >> > >> >> What would be the scenario where the new attribute is used? >> >> Colin >> >> >> >> >> >> --> "Dan Firac" writes: >> >> >It's a very good ideea. >> >> >Anyway, why this attribute was defined for ATM transport type only? >> >> >Silence suppression, as you pointed below, is an attribute of a codec >> >> >and has nothing to do with transport. >> >> > >> >> >Dan Firac, >> >> >Software Engineer, >> >> >RedlineCommunications, >> >> >Romania. >> >> > >> >> > >> >> > >> >> > >> >> >----- Original Message ----- >> >> >From: "Tom-PT Taylor" >> >> >To: ; >> >> >Sent: Wednesday, April 03, 2002 12:10 AM >> >> >Subject: [MMUSIC] Silence Suppression Attribute >> >> > >> >> > >> >> >> The issue of how to signal silence suppression capability >> keeps coming >> >up >> >> >on >> >> >> the Megaco list. The situation is fairly complicated: >> >> >> - some codecs come with a pre-defined capability for silence >> >suppression. >> >> >> This capability can be invoked by the appropriate MIME type >> parameter >> >as >> >> >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is >> specific to >> >RTP >> >> >> transport, arguably over UDP only. >> >> >> - other codecs like G.711 have no such parameter, yet silence >> >suppression >> >> >> is possible >> >> >> - RFC 3108 defined an a=silenceSupp attribute, but it >> applies to ATM >> >> >> transport only. >> >> >> >> >> >> How would people feel about allowing the a=silenceSupp >> parameter to be >> >> >used >> >> >> independently of the transport type? >> >> >> >> >> >> Tom Taylor >> >> >> taylor@nortelnetworks.com >> >> >> Ph. +1 613 736 0961 (ESN 396 1490) >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> mmusic mailing list >> >> >> mmusic@ietf.org >> >> >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> > >> >> > >> >> >_______________________________________________ >> >> >mmusic mailing list >> >> >mmusic@ietf.org >> >> >https://www1.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 19:23:14 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19853 for ; Thu, 11 Apr 2002 19:23:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24553; Thu, 11 Apr 2002 19:21:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA24508 for ; Thu, 11 Apr 2002 19:21:39 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19826 for ; Thu, 11 Apr 2002 19:21:36 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3BNL6MY024498; Thu, 11 Apr 2002 16:21:06 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id QAA22846; Thu, 11 Apr 2002 16:21:00 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Colin Perkins" Cc: "Dan Firac" , Subject: RE: [MMUSIC] Silence Suppression Attribute Date: Thu, 11 Apr 2002 16:21:00 -0700 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.2910.0) Importance: Normal In-Reply-To: <200204112103.g3BL39P03891@chiron.nge.isi.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit > Rajesh, > > I think this is a good start, but it needs a definition of the type of > parameter that can be included in the new attribute (and, depending on > the definition, a more appropriate name for the attribute). How about the following: Parameters which are meant to qualify specific payload types, but are not part of the MIME definition. These parameters would be defined generically i.e. not within a MIME definition. However, they would be applied to individual payload types, and not the media stream per se. These parameters would, of necessity, be optional and would provide value-adds in processing the formats (such as playout buffer optimization). By definition, they cannot be made mandatory. All mandatory parameters must be part of the MIME definition. Is there a problem with this definition? If so, then can the team help me refine it? It does provide a definite value add in the voiceband data case. It would be nice to have a standard, interoperable way of conveying this. > You have two examples: one affects the operation of the playout buffer, > the other affects part of the terminal outside the realm of RTP or the > packet network. I'm not sure it's appropriate to have such different > parameters signalled in a single attribute, but without a definition of > the attribute, it's difficult to tell what is appropriate. Per the definition above, the VBD flag would certainly be appropriate. The ECAN should be dropped since this should apply to the media stream as opposed to individual payload types. I do not know any other parameter that needs to be conveyed in this manner. Does anyone else? My original presentation was limited to VBD. However, there was a suggestion at the Minneapolis meeting that there might be a need for a broader construct. > > I also think the discussion of RFC 2198 should not be in this draft. Right. RFC 2198 applies to all RTP formats, and there is no need to state it here. Rajesh > > Colin > > > > > > --> "Rajesh Kumar" writes: > >Please comment on > >http://search.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-g > fmtp-00.txt > >. This might fit the "generic format parameters" Colin mentioned. > > > >Rajesh Kumar > >Cisco Systems > > > >> -----Original Message----- > >> From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > >> Colin Perkins > >> Sent: Friday, April 05, 2002 9:45 AM > >> To: Dan Firac > >> Cc: mmusic@ietf.org > >> Subject: Re: [MMUSIC] Silence Suppression Attribute > >> > >> > >> Dan, > >> > >> I think Steve's email mostly answers this. If the codec has > parameters to > >> determine how the silence suppression works, these need to be > specified as > >> part of the payload format. > >> > >> For just signalling the preference that that suppression not > be performed > >> (and clearly this can only be a preference), a "generic format > parameters" > >> is probably the best way to proceed, rather than a specific > attribute for > >> silence suppression. > >> > >> Colin > >> > >> > >> --> "Dan Firac" writes: > >> >It's about user preferences. > >> > > >> >Scenario: > >> >If the user prefers to DISABLE Silence Suppresion in order to > >> acheive higher > >> >audio quality, then the SDP composed by its phone should express > >> this wish. > >> > > >> >Further pros: > >> >1) Silence suppression it's a PARAMETER for many codecs, and > >> >I think it should be present in SDP offers/answers. > >> >2) When the remote end is not well tuned (ex: volumes), the VAD on the > >> >remote end may > >> >brutally cut the speech, so our local user will not know/feel if > >> there were > >> >loses or > >> >the remote user stopped speaking. > >> >3) The same thing happens when the local user has G723 without > >> AnnexA (VAD), > >> >G729 without AnnexB, and would want to force the remote end to use > >> >a codec without silence suppression. > >> > > >> >Points 2) and 3) are about gaining some quality. > >> > > >> >You are right, RTP assumes silence suppression and all the scenarios > >> >(including the above scenarios) are working without > negotiating Silence > >> >Suppression. > >> >But is the obtained quality the best quality that can be acheived????? > >> > > >> >I think the user should decide it and the SDP should offer him > >> >a mechanism (at least, optional) to express his preferences. > >> > > >> >Best regards, > >> >Dan Firac, > >> >Software Engineer, > >> >RedlineCommunications, > >> >Romania. > >> > > >> > > >> >----- Original Message ----- > >> >From: "Colin Perkins" > >> >To: "Dan Firac" > >> >Cc: "Tom-PT Taylor" ; > >> >Sent: Thursday, April 04, 2002 2:22 AM > >> >Subject: Re: [MMUSIC] Silence Suppression Attribute > >> > > >> > > >> >> What would be the scenario where the new attribute is used? > >> >> Colin > >> >> > >> >> > >> >> --> "Dan Firac" writes: > >> >> >It's a very good ideea. > >> >> >Anyway, why this attribute was defined for ATM transport type only? > >> >> >Silence suppression, as you pointed below, is an attribute > of a codec > >> >> >and has nothing to do with transport. > >> >> > > >> >> >Dan Firac, > >> >> >Software Engineer, > >> >> >RedlineCommunications, > >> >> >Romania. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >----- Original Message ----- > >> >> >From: "Tom-PT Taylor" > >> >> >To: ; > >> >> >Sent: Wednesday, April 03, 2002 12:10 AM > >> >> >Subject: [MMUSIC] Silence Suppression Attribute > >> >> > > >> >> > > >> >> >> The issue of how to signal silence suppression capability > >> keeps coming > >> >up > >> >> >on > >> >> >> the Megaco list. The situation is fairly complicated: > >> >> >> - some codecs come with a pre-defined capability for silence > >> >suppression. > >> >> >> This capability can be invoked by the appropriate MIME type > >> parameter > >> >as > >> >> >> defined in draft-ietf-avt-rtp-mime-06.txt. That draft is > >> specific to > >> >RTP > >> >> >> transport, arguably over UDP only. > >> >> >> - other codecs like G.711 have no such parameter, yet silence > >> >suppression > >> >> >> is possible > >> >> >> - RFC 3108 defined an a=silenceSupp attribute, but it > >> applies to ATM > >> >> >> transport only. > >> >> >> > >> >> >> How would people feel about allowing the a=silenceSupp > >> parameter to be > >> >> >used > >> >> >> independently of the transport type? > >> >> >> > >> >> >> Tom Taylor > >> >> >> taylor@nortelnetworks.com > >> >> >> Ph. +1 613 736 0961 (ESN 396 1490) > >> >> >> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> mmusic mailing list > >> >> >> mmusic@ietf.org > >> >> >> https://www1.ietf.org/mailman/listinfo/mmusic > >> >> > > >> >> > > >> >> >_______________________________________________ > >> >> >mmusic mailing list > >> >> >mmusic@ietf.org > >> >> >https://www1.ietf.org/mailman/listinfo/mmusic > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mmusic > > > > > >_______________________________________________ > >mmusic mailing list > >mmusic@ietf.org > >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 20:53:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22151 for ; Thu, 11 Apr 2002 20:53:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28800; Thu, 11 Apr 2002 20:45:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28765 for ; Thu, 11 Apr 2002 20:45:26 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21987 for ; Thu, 11 Apr 2002 20:45:22 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3C0jIMr000564; Thu, 11 Apr 2002 20:45:18 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204120045.g3C0jIMr000564@purple.nge.isi.edu> To: Rohan Mahy cc: David Yon , mmusic@ietf.org Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Tue, 09 Apr 2002 09:54:20 PDT." Date: Thu, 11 Apr 2002 20:45:18 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> Rohan Mahy writes: ... >> > - Section 2.6 says that you MUST NOT send media on a passive port until >> > a packet has been received. Does this include not sending RTCP? >> >> I got that language from Rohan Mahy. Rohan? Clarification? > >Short answer is: the passive peer can't send RTP until it has recieved a >packet of RTP on the RTP port, and can't send RTCP until it has received a >packet of RTCP on the RTCP port. > >You can't (and MUST NOT) send RTP, RTCP, UDP, TCP, etc... media from a >passive port until a packet has arrived to that port from (presumably) the >active peer. The reason is simple--you don't know the address/port of >your peer until your recieve that first packet. > >hope this helps. Okay, that helps. Maybe the discussion in the draft could be expanded though, to ensure there's no confusion? Cheers, Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 20:53:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22162 for ; Thu, 11 Apr 2002 20:53:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28871; Thu, 11 Apr 2002 20:46:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28839 for ; Thu, 11 Apr 2002 20:46:49 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22037 for ; Thu, 11 Apr 2002 20:46:45 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3C0keMr000583; Thu, 11 Apr 2002 20:46:40 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204120046.g3C0keMr000583@purple.nge.isi.edu> To: "David Yon" cc: "Rohan Mahy" , mmusic@ietf.org Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Thu, 11 Apr 2002 11:52:21 EDT." Date: Thu, 11 Apr 2002 20:46:40 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: > > >> Short answer is: the passive peer can't send RTP until it has >> recieved a >> packet of RTP on the RTP port, and can't send RTCP until it >> has received a >> packet of RTCP on the RTCP port. >> >> You can't (and MUST NOT) send RTP, RTCP, UDP, TCP, etc... >> media from a >> passive port until a packet has arrived to that port from >> (presumably) the >> active peer. The reason is simple--you don't know the address/port of >> your peer until your recieve that first packet. >> > >Ok, unless there are objections, I'm changing the sentence to read: > > Endpoints that specify direction:passive MUST NOT > send any media, including control packets such as > RTCP, from their passive ports until they receive > a packet on these ports and record the source address > and port of the sender. I think it needs to say "MUST NOT send RTP until it has received an RTP packet on the passive port; MUST NOT send RTCP until it has received an RTCP packet on the passive port". Be explicit about it. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 20:53:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22175 for ; Thu, 11 Apr 2002 20:53:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28721; Thu, 11 Apr 2002 20:43:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA28692 for ; Thu, 11 Apr 2002 20:43:50 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21922 for ; Thu, 11 Apr 2002 20:43:45 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3C0hXMr000541; Thu, 11 Apr 2002 20:43:37 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204120043.g3C0hXMr000541@purple.nge.isi.edu> To: "David Yon" cc: mmusic@ietf.org, "Rohan Mahy" Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Tue, 09 Apr 2002 10:37:29 EDT." Date: Thu, 11 Apr 2002 20:43:33 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: >Thanks Colin for looking over the draft in such detail. Comments inline >below. > >> >> - The Protocol Identifiers section may want to point to the >> discussion of >> m= in SDP, which specifies that the identifiers are MIME >> subtypes for >> audio/video/application media types. This is implicit in >> the examples, >> and explicit in SDP, but not noted in this draft. >> > >I will add the following text to the "Protocol Identifiers" section >(directly before the "TCP" section): > > The m= line in [SDP] is where an endpoint specifies the protocol > > used for the media in the session. See the "Media Announcements" > section of [SDP] for a discussion on protocol identifiers Okay, looks good. >> - How specific is this to SDP used with offer/answer? It's probably >> appropriate to have a section explaining how comedia is used with >> SIP (i.e. offer/answer), RTSP, MEGACO and perhaps SAP. >> > >In SIP I believe it is equally relevant to both offer/answer and >three-way handshake (INVITE/OK/ACK). I made an attempt to describe the >semantics in protocol-independant manner to reduce the dependencies of >this draft, and I think that the language describes the scenarios >correctly. The two sections where this is most visible are the >"Optimizing direction:both" and "Connection and Listener Lifetime >Considerations". It would be helpful if those that are more familiar >with the upper-level protocols (especially RSTP and MEGACO) would check >the language to make sure that there are not impedance mismatches >introduced to those protocols. Thanks, that clarifies. >> - In section 3, how is the source address useful given that it can't be >> trusted? More explanation of how it can be used is probably needed. > >There is a big "NOTE:" section in "Source-Address Considerations" that >covers this. What am I missing? Do either of those uses make sense if the source address can be spoofed? Firewalls that open ported based on untrusted SDP seem to be a risk, and you list problems with session identification. I just think it could do with more discussion of the risks and benefits tradeoff, maybe something in the security considerations. >> - Section 4.1: the time window is the t= line? > >The t= line is not directly referenced since I believe the endpoint's >time window semantics can be derived from other sources (SIP Session >Timer comes to mind). Okay, but what if the t= line contradicts? Which takes precedence? >> - The possible race when both parties select diraction:both >> concerns me, >> but I'm not sure I can see a better alternative (unless >> there's some >> trick to make one side win deterministically, for example >> the lowest >> IP address wins). > >Short of mechanisms that involve additional handshaking by the upper >layer protocol, I saw no way to completely eliminate the race. Keep in >mind that the two-connection condition is not fatal (nor even that >cumbersome, since existing RTP/UDP implementations already have to track >different transport information for inbound vs outbound media), and that >the suggested mechanism should sufficiently reduce the likelihood of the >race that excess resource utilization should be minimized. Okay. Cheers, Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 21:01:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22352 for ; Thu, 11 Apr 2002 21:01:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29530; Thu, 11 Apr 2002 21:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29503 for ; Thu, 11 Apr 2002 21:00:55 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22334 for ; Thu, 11 Apr 2002 21:00:50 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3C0wGMr000625; Thu, 11 Apr 2002 20:58:16 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204120058.g3C0wGMr000625@purple.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Tue, 09 Apr 2002 11:28:11 +0200." <0DAEDF148988D411BB980008C7E65D2E04FE4154@esealnt416> Date: Thu, 11 Apr 2002 20:58:16 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Fredrik Lindholm (ERA)" writes: > > >> >> --> "Fredrik Lindholm (ERA)" writes: >> ... >> >So, is your recommendation then that we should register a unique >> >a=mikey: >> >attribute (and similar for RTSP?) instead of going on with the >> >approach in the current draft? How would you like us to proceed? >> >> I think it depends on how many key management protocols we're >> likely to >> see. If MIKEY is the only one, then a=mikey: is appropriate. >> But, if we >> expect to have many key exchange protocols, Steve's concerns >> about name >> space pollution are important, and an "a=key-mgmt:mikey " >> attribute may be better (because it establishes a separate >> namespace for >> key exchange protocol names). >> >> However, my main concern is the use of opaque (to SDP) data >> in the first >> place. I'd be much happier if the key exchange could happen >> as part of a >> standard offer/answer within SDP, rather than being tunneled. > >I still vote for the use of the opaque approach. A new reason is due >to the re-counting I did of how many parameters we would need to >define in SDP (for MIKEY), which is 31 + (#SRTP parameters needed). >I.e. this would result in "quite a few" new attributes. The MIKEY ...which have to be defined anyway. The only difference is that they are defined as parameters to an SDP attribute, rather than binary parameters to MIKEY. >message will probably expand with a factor between 2 and 5 (compared >to a base64 encoded MIKEY message). Another problem with this would This may be an issue, certainly. >of course be that if a payload would be added (e.g. support a new >security protocol) would require a change in SDP (as new parameters >might be introduced by the new security protocol). It would require the addition of a new parameter to the SDP attribute registry, true. However the alternative is adding a new parameter to a MIKEY registry, so I don't see the gain. >Unless you oppose completely, I would like to go on with the opaque >approach. I do not expect that the number of key management protocols >that will use the attribute exceeds 4 in the near future (as I only >see 3 alternatives right now). So the question is then, whether to use >the a=mikey: or to use the a=key-mgmt:mikey . Probably the latter, if we go with this approach. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 11 21:29:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25127 for ; Thu, 11 Apr 2002 21:29:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00623; Thu, 11 Apr 2002 21:28:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00588 for ; Thu, 11 Apr 2002 21:28:44 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25049 for ; Thu, 11 Apr 2002 21:28:39 -0400 (EDT) Received: from purple.nge.isi.edu (localhost.nge.isi.edu [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3C1Scug000555; Thu, 11 Apr 2002 21:28:39 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204120128.g3C1Scug000555@purple.nge.isi.edu> To: Prashant Gupta cc: mmusic@ietf.org Subject: Re: [MMUSIC] Query regarding a=type: attribute In-Reply-To: Your message of "Tue, 09 Apr 2002 20:09:47 EDT." <3CB382CB.FC5A00D@unity.ncsu.edu> Date: Thu, 11 Apr 2002 21:28:38 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi, --> Prashant Gupta writes: >>From draft-ietf-mmusic-sdp-new-06 pg 26, a=type:moderated attribute >should start the media tools in a "mute" mode. Does this imply that the >a=inactive attribute is implied by the above for each of the media >lines? I guess so, they both imply that no media is sent. Does it matter? >A related query is that, what exactly do SDP attributes for media lines >describe? Do they indicate the current state of the media stream or do >they indicate the nature of the media stream. > >To clarify a little, I am wondering if there is a need for an "update" >in SDP attributes, when say, a particular conference participant is not >given the right to address the conference by a moderator (this doesnt >change the basic nature of the media being sendrecv, but is just >temporarily not giving the user permissions to send/recv this stream). This probably depends on how the SDP is used. If you're using SDP as part of a floor control protocol, then I'd expect new SDP to be exchanged (the semantics of this are not clear though). If SDP just sets up the session, then it would describe the initial state and the floor control protocol would handle updates. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 12 02:31:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09268 for ; Fri, 12 Apr 2002 02:31:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24466; Fri, 12 Apr 2002 02:23:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA24433 for ; Fri, 12 Apr 2002 02:23:34 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08217 for ; Fri, 12 Apr 2002 02:23:31 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3C6NW3G003224 for ; Fri, 12 Apr 2002 08:23:32 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Apr 12 08:25:21 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Apr 2002 08:13:09 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4164@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Colin Perkins'" Cc: mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Fri, 12 Apr 2002 08:22:48 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > > --> "Fredrik Lindholm (ERA)" writes: > > > > > >> > >> --> "Fredrik Lindholm (ERA)" writes: > >> ... > >> >So, is your recommendation then that we should register a unique > >> >a=mikey: > >> >attribute (and similar for RTSP?) instead of going on with the > >> >approach in the current draft? How would you like us to proceed? > >> > >> I think it depends on how many key management protocols we're > >> likely to > >> see. If MIKEY is the only one, then a=mikey: is appropriate. > >> But, if we > >> expect to have many key exchange protocols, Steve's concerns > >> about name > >> space pollution are important, and an "a=key-mgmt:mikey > " > >> attribute may be better (because it establishes a separate > >> namespace for > >> key exchange protocol names). > >> > >> However, my main concern is the use of opaque (to SDP) data > >> in the first > >> place. I'd be much happier if the key exchange could happen > >> as part of a > >> standard offer/answer within SDP, rather than being tunneled. > > > >I still vote for the use of the opaque approach. A new reason is due > >to the re-counting I did of how many parameters we would need to > >define in SDP (for MIKEY), which is 31 + (#SRTP parameters needed). > >I.e. this would result in "quite a few" new attributes. The MIKEY > > ...which have to be defined anyway. The only difference is > that they are > defined as parameters to an SDP attribute, rather than binary > parameters > to MIKEY. That's not really true. You would need to define these parameters to RTSP as well. And if there appears the need of using MIKEY in other protocols, we would then need to re-define all parameters again. > > >message will probably expand with a factor between 2 and 5 (compared > >to a base64 encoded MIKEY message). Another problem with this would > > This may be an issue, certainly. > > >of course be that if a payload would be added (e.g. support a new > >security protocol) would require a change in SDP (as new parameters > >might be introduced by the new security protocol). > > It would require the addition of a new parameter to the SDP attribute > registry, true. However the alternative is adding a new > parameter to a > MIKEY registry, so I don't see the gain. No, one new parameters would impact not only SDP, but RTSP as well (and any other protocol that MIKEY might use for transport). That's why MIKEY needs its own registry space (I would claim that holds for any key management protocol). Fredrik > > >Unless you oppose completely, I would like to go on with the opaque > >approach. I do not expect that the number of key management > protocols > >that will use the attribute exceeds 4 in the near future (as I only > >see 3 alternatives right now). So the question is then, > whether to use > >the a=mikey: or to use the a=key-mgmt:mikey > . > > Probably the latter, if we go with this approach. > > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 12 16:37:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03474 for ; Fri, 12 Apr 2002 16:37:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11761; Fri, 12 Apr 2002 16:33:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11730 for ; Fri, 12 Apr 2002 16:33:49 -0400 (EDT) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03344 for ; Fri, 12 Apr 2002 16:33:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message Subject: RE: [MMUSIC] Prelim copy of comedia-02 available MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 12 Apr 2002 16:33:20 -0400 Message-ID: Thread-Topic: [MMUSIC] Prelim copy of comedia-02 available Thread-Index: AcHhuxqntjfgxIqBSXij8VuzqhOMngAo098Q From: "David Yon" To: "Colin Perkins" Cc: , "Rohan Mahy" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA11731 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit > > >> - In section 3, how is the source address useful given > that it can't be > >> trusted? More explanation of how it can be used is > probably needed. > > > >There is a big "NOTE:" section in "Source-Address > Considerations" that > >covers this. What am I missing? > > Do either of those uses make sense if the source address can > be spoofed? > Firewalls that open ported based on untrusted SDP seem to be > a risk, and > you list problems with session identification. I just think > it could do > with more discussion of the risks and benefits tradeoff, > maybe something > in the security considerations. > The firewall security issue is a good point. The dynamic NAT mapping isn't really a security issue as a generic NAT function isn't intended to offer security. For example, my SMC Barricade allows me to specify dynamic bindings that are created in response to other network activity, none of it validated or "trusted". In such a scenario, an internal ALP in the NAT box that translates the source address/port and sets up a dynamic mapping would be perfectly appropriate. For firewalls, SDP being untrusted is not a given. There could be a chain of trust from the firewall to the local SIP proxy back to trusted/authenticated UA's where the SDP originates. I can add a general comment in the security considerations that mentions that in the case of dynamic firewall pinholes that the trust/spoofing issues must be taken into account. Does that address your concern? > >> - Section 4.1: the time window is the t= line? > > > >The t= line is not directly referenced since I believe the endpoint's > >time window semantics can be derived from other sources (SIP Session > >Timer comes to mind). > > Okay, but what if the t= line contradicts? Which takes precedence? > That's context specific, and it's outside of comedia's scope. The point I'm driving at is that the endpoints have *somehow* unambiguously communicated to each other a time window. SDP's t= line is but one place that this happens. Comedia cannot dictate when t= does or does not take precedence. Another way to look at it: in whatever manner the endpoints communicate this time window, comedia changes nothing about the semantics of said time window nor how it should be communicated. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 12 16:40:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03576 for ; Fri, 12 Apr 2002 16:40:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11829; Fri, 12 Apr 2002 16:34:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA11784 for ; Fri, 12 Apr 2002 16:34:38 -0400 (EDT) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03354 for ; Fri, 12 Apr 2002 16:34:34 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message Subject: RE: [MMUSIC] Prelim copy of comedia-02 available MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 12 Apr 2002 16:34:09 -0400 Message-ID: Thread-Topic: [MMUSIC] Prelim copy of comedia-02 available Thread-Index: AcHhu4ZhQdD03LzKTCKUXLc/yoBwfwAoly4w From: "David Yon" To: "Colin Perkins" Cc: "Rohan Mahy" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA11785 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit > > > >Ok, unless there are objections, I'm changing the sentence to read: > > > > Endpoints that specify direction:passive MUST NOT > > send any media, including control packets such as > > RTCP, from their passive ports until they receive > > a packet on these ports and record the source address > > and port of the sender. > > I think it needs to say "MUST NOT send RTP until it has > received an RTP > packet on the passive port; MUST NOT send RTCP until it has > received an > RTCP packet on the passive port". Be explicit about it. > > Colin > Except that there are other protocols in the world besides those based on RTP/RTCP. Rohan's language specifically includes other protocols (hence the UDP reference). T.38 over UDP, for example, would not be addressed by your proposed language. Given the need to include the entire set of media types in Rohan's language, I'm still of the opinion that my proposed language above is unambigious to the alert reader, even if they have RTP/RTCP in mind. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 12 17:09:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04342 for ; Fri, 12 Apr 2002 17:09:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13981; Fri, 12 Apr 2002 17:08:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13946 for ; Fri, 12 Apr 2002 17:08:06 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04288 for ; Fri, 12 Apr 2002 17:08:02 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3CL7wD15803; Fri, 12 Apr 2002 17:07:58 -0400 Message-Id: <200204122107.g3CL7wD15803@chiron.nge.isi.edu> To: "David Yon" cc: "Rohan Mahy" , mmusic@ietf.org Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Fri, 12 Apr 2002 16:34:09 EDT." Date: Fri, 12 Apr 2002 17:07:58 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: > > >> > >> >Ok, unless there are objections, I'm changing the sentence to read: >> > >> > Endpoints that specify direction:passive MUST NOT >> > send any media, including control packets such as >> > RTCP, from their passive ports until they receive >> > a packet on these ports and record the source address >> > and port of the sender. >> >> I think it needs to say "MUST NOT send RTP until it has >> received an RTP >> packet on the passive port; MUST NOT send RTCP until it has >> received an >> RTCP packet on the passive port". Be explicit about it. > >Except that there are other protocols in the world besides those based >on RTP/RTCP. Rohan's language specifically includes other protocols >(hence the UDP reference). T.38 over UDP, for example, would not be >addressed by your proposed language. True. >Given the need to include the entire set of media types in Rohan's >language, I'm still of the opinion that my proposed language above is >unambigious to the alert reader, even if they have RTP/RTCP in mind. I'm not too worried about it. You could add a "For example, if using RTP, ..." maybe? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 12 17:20:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04486 for ; Fri, 12 Apr 2002 17:20:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14498; Fri, 12 Apr 2002 17:17:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14461 for ; Fri, 12 Apr 2002 17:17:49 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04469 for ; Fri, 12 Apr 2002 17:17:45 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3CLHmj15907; Fri, 12 Apr 2002 17:17:48 -0400 Message-Id: <200204122117.g3CLHmj15907@chiron.nge.isi.edu> To: "David Yon" cc: mmusic@ietf.org, "Rohan Mahy" Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Fri, 12 Apr 2002 16:33:20 EDT." Date: Fri, 12 Apr 2002 17:17:48 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: >> >> >> - In section 3, how is the source address useful given >> that it can't be >> >> trusted? More explanation of how it can be used is >> probably needed. >> > >> >There is a big "NOTE:" section in "Source-Address >> Considerations" that >> >covers this. What am I missing? >> >> Do either of those uses make sense if the source address can >> be spoofed? >> Firewalls that open ported based on untrusted SDP seem to be >> a risk, and >> you list problems with session identification. I just think >> it could do >> with more discussion of the risks and benefits tradeoff, >> maybe something >> in the security considerations. >> > >The firewall security issue is a good point. The dynamic NAT mapping >isn't really a security issue as a generic NAT function isn't intended >to offer security. For example, my SMC Barricade allows me to specify >dynamic bindings that are created in response to other network activity, >none of it validated or "trusted". In such a scenario, an internal ALP >in the NAT box that translates the source address/port and sets up a >dynamic mapping would be perfectly appropriate. > >For firewalls, SDP being untrusted is not a given. There could be a >chain of trust from the firewall to the local SIP proxy back to >trusted/authenticated UA's where the SDP originates. I can add a >general comment in the security considerations that mentions that in the >case of dynamic firewall pinholes that the trust/spoofing issues must be >taken into account. > >Does that address your concern? Yes. >> >> - Section 4.1: the time window is the t= line? >> > >> >The t= line is not directly referenced since I believe the endpoint's >> >time window semantics can be derived from other sources (SIP Session >> >Timer comes to mind). >> >> Okay, but what if the t= line contradicts? Which takes precedence? >> > >That's context specific, and it's outside of comedia's scope. The point >I'm driving at is that the endpoints have *somehow* unambiguously >communicated to each other a time window. SDP's t= line is but one >place that this happens. Comedia cannot dictate when t= does or does >not take precedence. > >Another way to look at it: in whatever manner the endpoints communicate >this time window, comedia changes nothing about the semantics of said >time window nor how it should be communicated. Okay. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Apr 13 11:48:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25878 for ; Sat, 13 Apr 2002 11:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06358; Sat, 13 Apr 2002 11:44:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06325 for ; Sat, 13 Apr 2002 11:44:27 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25862 for ; Sat, 13 Apr 2002 11:44:23 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3DFiIf08209; Sat, 13 Apr 2002 17:44:18 +0200 (MEST) Message-ID: <3CB8527E.C6DE1BDB@tzi.uni-bremen.de> Date: Sat, 13 Apr 2002 17:45:02 +0200 From: Joerg Ott X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Fredrik Lindholm (ERA)" CC: "'Colin Perkins'" , mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion References: <0DAEDF148988D411BB980008C7E65D2E04FE4154@esealnt416> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Since we have talked about potential further key management protocols: the draft talks about this but does not specify how to negotiate the key management protocol: Let's assume (without stating consent here) that we use the following notation: m=audio ... a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... In this case, how do I specify that I am support two different schemes: "mikey" and "magic"? Is this going to be a single m= line m=audio ... a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... a=key-mgmt:magic data=jhas84hjkH9hjkSaDH38... which means that the key-mgmt attributes implicitly carries the semantics that the intersection of the algorithms is constructed and, in the offer/answer case, the answerer picks the one to use. Or, do I allow only exactly one key-mgmt attribute per m= line or session, use two a number media lines and group those somehow? Or shall only one be allowed at all and the initiator may need to try one by one? In either case, the spec needs to specify whether the initiator what the intended outcome is. I assume that non-availability of the requested key management protocol at the receiver will lead to a rejection of the offer? Or is "none" an acceptable outcome? This also needs to be specified. Of course, making the key management negotiable brings up the issues of bidding down attacks that we had in the context of SIP security. Regardless of the syntactical representation, this problem needs to be addressed. Joerg > > > > > --> "Fredrik Lindholm (ERA)" writes: > > ... > > >So, is your recommendation then that we should register a unique > > >a=mikey: > > >attribute (and similar for RTSP?) instead of going on with the > > >approach in the current draft? How would you like us to proceed? > > > > I think it depends on how many key management protocols we're > > likely to > > see. If MIKEY is the only one, then a=mikey: is appropriate. > > But, if we > > expect to have many key exchange protocols, Steve's concerns > > about name > > space pollution are important, and an "a=key-mgmt:mikey " > > attribute may be better (because it establishes a separate > > namespace for > > key exchange protocol names). > > > > However, my main concern is the use of opaque (to SDP) data > > in the first > > place. I'd be much happier if the key exchange could happen > > as part of a > > standard offer/answer within SDP, rather than being tunneled. > > I still vote for the use of the opaque approach. A new reason is due > to the re-counting I did of how many parameters we would need to > define in SDP (for MIKEY), which is 31 + (#SRTP parameters needed). > I.e. this would result in "quite a few" new attributes. The MIKEY > message will probably expand with a factor between 2 and 5 (compared > to a base64 encoded MIKEY message). Another problem with this would > of course be that if a payload would be added (e.g. support a new > security protocol) would require a change in SDP (as new parameters > might be introduced by the new security protocol). > > Unless you oppose completely, I would like to go on with the opaque > approach. I do not expect that the number of key management protocols > that will use the attribute exceeds 4 in the near future (as I only > see 3 alternatives right now). So the question is then, whether to use > the a=mikey: or to use the a=key-mgmt:mikey . > > Fredrik > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sun Apr 14 23:44:47 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28033 for ; Sun, 14 Apr 2002 23:44:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00060; Sun, 14 Apr 2002 23:43:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA00016 for ; Sun, 14 Apr 2002 23:43:12 -0400 (EDT) Received: from DESKTOP (h00207818a19b.ne.client2.attbi.com [24.60.238.3]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28023 for ; Sun, 14 Apr 2002 23:43:08 -0400 (EDT) Message-Id: <200204150343.XAA28023@ietf.org> From: "Adam Erickson" To: Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Sun, 14 Apr 2002 23:43:36 -0400 Subject: [MMUSIC] Resume Writing and Distribution Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Dear Job Seeker,


How can we help you find your DREAM JOB?

Resume Author.com is an established resume writing and distribution firm that specializes in custom-tailored career development. We have a dedicated staff of resume writers and an Opt-In E-mail Distribution Network of over 19,000 recruiters and employers (We can have your professional resume in their hands in a matter of minutes).

We're so confident in the effectiveness of our services that we guarantee job interviews!!!

Learn more about the most effective career marketing services available.

Resume Writing & Editing Services Click Here
Starting at only 79.95

E-mail Resume Distribution Services Click Here
Starting at only 29.95


Best Regards,

Adam Erickson
Client Development,
Resume Author


Would you like to test our quality? We provide a FREE Resume Critique for all interested parties.




CONCERNED ABOUT JUNK MAIL? SO ARE WE.

As a ResumeAuthor.com Sales Representative, I believe you meet the criteria we look for in a resume writing and distribution customer. If, however, you feel that you have received this email in error, I apologize. We will comply with all removal requests. To be removed type "remove" in the subject line and MAIL TO:aerickson@resumeauthor.com this is the only way to be removed. Hitting reply will NOT remove you.

This message is sent in compliance of the new email bill section 301.Per Section 301, Paragraph (a)(2)(C) of S. 1618. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 08:43:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15394 for ; Mon, 15 Apr 2002 08:43:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09724; Mon, 15 Apr 2002 08:40:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA09688 for ; Mon, 15 Apr 2002 08:40:14 -0400 (EDT) Received: from dnimail.Dialout.net ([206.183.139.197]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15121 for ; Mon, 15 Apr 2002 08:40:10 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message Subject: RE: [MMUSIC] Prelim copy of comedia-02 available MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 15 Apr 2002 08:39:42 -0400 Message-ID: Thread-Topic: [MMUSIC] Prelim copy of comedia-02 available Thread-Index: AcHiZ4ApkaDhyJOdTIShANsve1CoHwCErypQ From: "David Yon" To: "Colin Perkins" Cc: , "Joerg Ott" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id IAA09689 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Colin, thanks again for the timely and detailed feedback. I've posted an updated copy at: http://www.dialout.net/public/ietf/draft-ietf-mmusic-sdp-comedia-02.txt This copy has incorporated all feedback to date. I will fix the non-ASCII character problem when I submit the official copy. Jeorg/Colin, ready for Last Call? Should I go ahead and submit this version to the ID queue? > -----Original Message----- > From: Colin Perkins [mailto:csp@isi.edu] > Sent: Friday, April 12, 2002 5:18 PM > To: David Yon > Cc: mmusic@ietf.org; Rohan Mahy > Subject: Re: [MMUSIC] Prelim copy of comedia-02 available > > > --> "David Yon" writes: > >> > >> >> - In section 3, how is the source address useful given > >> that it can't be > >> >> trusted? More explanation of how it can be used is > >> probably needed. > >> > > >> >There is a big "NOTE:" section in "Source-Address > >> Considerations" that > >> >covers this. What am I missing? > >> > >> Do either of those uses make sense if the source address can > >> be spoofed? > >> Firewalls that open ported based on untrusted SDP seem to be > >> a risk, and > >> you list problems with session identification. I just think > >> it could do > >> with more discussion of the risks and benefits tradeoff, > >> maybe something > >> in the security considerations. > >> > > > >The firewall security issue is a good point. The dynamic NAT mapping > >isn't really a security issue as a generic NAT function > isn't intended > >to offer security. For example, my SMC Barricade allows me > to specify > >dynamic bindings that are created in response to other > network activity, > >none of it validated or "trusted". In such a scenario, an > internal ALP > >in the NAT box that translates the source address/port and sets up a > >dynamic mapping would be perfectly appropriate. > > > >For firewalls, SDP being untrusted is not a given. There could be a > >chain of trust from the firewall to the local SIP proxy back to > >trusted/authenticated UA's where the SDP originates. I can add a > >general comment in the security considerations that mentions > that in the > >case of dynamic firewall pinholes that the trust/spoofing > issues must be > >taken into account. > > > >Does that address your concern? > > Yes. > > >> >> - Section 4.1: the time window is the t= line? > >> > > >> >The t= line is not directly referenced since I believe > the endpoint's > >> >time window semantics can be derived from other sources > (SIP Session > >> >Timer comes to mind). > >> > >> Okay, but what if the t= line contradicts? Which takes precedence? > >> > > > >That's context specific, and it's outside of comedia's > scope. The point > >I'm driving at is that the endpoints have *somehow* unambiguously > >communicated to each other a time window. SDP's t= line is but one > >place that this happens. Comedia cannot dictate when t= does or does > >not take precedence. > > > >Another way to look at it: in whatever manner the endpoints > communicate > >this time window, comedia changes nothing about the semantics of said > >time window nor how it should be communicated. > > Okay. > > Colin > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 11:25:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20393 for ; Mon, 15 Apr 2002 11:25:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20376; Mon, 15 Apr 2002 11:17:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA20343 for ; Mon, 15 Apr 2002 11:17:33 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20251 for ; Mon, 15 Apr 2002 11:17:27 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3FFHTs7005557 for ; Mon, 15 Apr 2002 17:17:29 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Apr 15 17:17:25 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JBTLDXV>; Mon, 15 Apr 2002 17:17:25 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE4176@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Joerg Ott'" Cc: "'Colin Perkins'" , mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Mon, 15 Apr 2002 17:16:42 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org > > Since we have talked about potential further key management protocols: > the draft talks about this but does not specify how to negotiate the > key management protocol: > > Let's assume (without stating consent here) that we use the following > notation: > > m=audio ... > a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... > > In this case, how do I specify that I am support two > different schemes: > "mikey" and "magic"? > > Is this going to be a single m= line > > m=audio ... > a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... > a=key-mgmt:magic data=jhas84hjkH9hjkSaDH38... > > which means that the key-mgmt attributes implicitly carries the > semantics that the intersection of the algorithms is constructed > and, in the offer/answer case, the answerer picks the one to use. > > Or, do I allow only exactly one key-mgmt attribute per m= line > or session, use two a number media lines and group those somehow? > > Or shall only one be allowed at all and the initiator may need to > try one by one? > > In either case, the spec needs to specify whether the initiator > what the intended outcome is. I assume that non-availability > of the requested key management protocol at the receiver will lead > to a rejection of the offer? Or is "none" an acceptable outcome? > This also needs to be specified. > > Of course, making the key management negotiable brings up the > issues of bidding down attacks that we had in the context of SIP > security. > > Regardless of the syntactical representation, this problem needs > to be addressed. Good point. I think that the best approach will be that the offerer include only one key mgmt suggestion in the first offer. If the answerer does not support the suggested protocol, it should in its response, indicate the protocols supported by including a key mgmt attribute with the name of the protocol(s) supported (but no data in it). I will include these kind of considerations in the next version of the draft. Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 13:58:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00209 for ; Mon, 15 Apr 2002 13:58:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02027; Mon, 15 Apr 2002 13:50:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01993 for ; Mon, 15 Apr 2002 13:50:25 -0400 (EDT) Received: from purple.nge.isi.edu (wireless79.east.isi.edu [65.114.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29886 for ; Mon, 15 Apr 2002 13:50:23 -0400 (EDT) Received: from purple (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3FHo4eI009468; Mon, 15 Apr 2002 13:50:10 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204151750.g3FHo4eI009468@purple.nge.isi.edu> To: "David Yon" cc: mmusic@ietf.org, "Joerg Ott" Subject: Re: [MMUSIC] Prelim copy of comedia-02 available In-Reply-To: Your message of "Mon, 15 Apr 2002 08:39:42 EDT." Date: Mon, 15 Apr 2002 13:50:04 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "David Yon" writes: >Colin, thanks again for the timely and detailed feedback. I've posted >an updated copy at: > >http://www.dialout.net/public/ietf/draft-ietf-mmusic-sdp-comedia-02.txt > >This copy has incorporated all feedback to date. I will fix the >non-ASCII character problem when I submit the official copy. > >Jeorg/Colin, ready for Last Call? Should I go ahead and submit this >version to the ID queue? Yes, please submit it to the i-d archive. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 16:57:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06519 for ; Mon, 15 Apr 2002 16:57:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13588; Mon, 15 Apr 2002 16:53:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13552 for ; Mon, 15 Apr 2002 16:53:49 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06460 for ; Mon, 15 Apr 2002 16:53:43 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g3FKr5KR012407 for ; Mon, 15 Apr 2002 13:53:05 -0700 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g3FKrDxu018922 for ; Mon, 15 Apr 2002 13:53:13 -0700 Date: Mon, 15 Apr 2002 13:56:07 -0700 (Pacific Daylight Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: Telecon agenda for April 10 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, Another Wednesday telecon is coming up this week. One of these days, we'll actually make it through more than the first couple of bullet points. :) This agenda will be on http://rtsp.org/telecon sometime tomorrow. In the meantime, it's included below. Please RSVP by 5pm Tuesday PST. Thanks Rob * Close on other decisions in Wednesday RTSP discussion (15 minutes) * Clarify aggregate/non-aggregate control * Reworked state machine (continuing discussion from last week) 4. Should we have the READY-nm state that the 0.4 state machine shows? 5. When doing setup for recording is there a requirement to have done announce before? 6. Should REDIRECT without range or reaching the readirect point result in imediatly closeing of the session? This is suggested by the old client state machine that send the client to Init on redirect. The text in chapter 10.10 says that the client should issue a teardown of previous session. * Should we eliminate queued play? (yes) 1. How do you queue timed PLAY requests 2. Implementation of accurate RTP-Info for queued play 3. Very complex interaction with MUTE 4. Lack of implementer interest - Not sure what practical use cases are * RECORD....needs specification work from implementer (may need to drop) * Specifications/groups which may extend RTSP * MUTE/UNMUTE * Transport model requirements * Is persistent TCP mode required? (yes) * Is non-persistent TCP mode required? (no, will define feature tag and "Supported" header from SIP) * Define roadmap for RTSP * Interop logistics * Registration of feature tags for optional features (need to audit spec) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 16:58:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06580 for ; Mon, 15 Apr 2002 16:58:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13804; Mon, 15 Apr 2002 16:56:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13770 for ; Mon, 15 Apr 2002 16:56:43 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06510 for ; Mon, 15 Apr 2002 16:56:38 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g3FKu1KR012586 for ; Mon, 15 Apr 2002 13:56:01 -0700 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g3FKu9xu021376 for ; Mon, 15 Apr 2002 13:56:09 -0700 Date: Mon, 15 Apr 2002 13:59:02 -0700 (Pacific Daylight Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP telecon: reducing frequency Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, One thing I forgot to mention in the telecon agenda. I'd like to discuss the possibility of reducing the frequency of the teleconferences, since the telecon is out so far in front of where the RTSP spec is right now. The idea would be that we'd shift focus to actually producing another version of RTSP that more accurately reflects what the thinking is on the telecon, and use that as a conversation topic. This will be the first topic on the telecon on Wednesday. Rob _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 17:56:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07553 for ; Mon, 15 Apr 2002 17:56:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16867; Mon, 15 Apr 2002 17:53:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA16836 for ; Mon, 15 Apr 2002 17:53:16 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07521 for ; Mon, 15 Apr 2002 17:53:10 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3FLr9S27391; Mon, 15 Apr 2002 17:53:09 -0400 Message-Id: <200204152153.g3FLr9S27391@chiron.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: "'Joerg Ott'" , mmusic@ietf.org, "Elisabetta Carrara (ERA)" Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Mon, 15 Apr 2002 17:16:42 +0200." <0DAEDF148988D411BB980008C7E65D2E04FE4176@esealnt416> Date: Mon, 15 Apr 2002 17:53:09 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Fredrik Lindholm (ERA)" writes: > >> >> Since we have talked about potential further key management protocols: >> the draft talks about this but does not specify how to negotiate the >> key management protocol: >> >> Let's assume (without stating consent here) that we use the following >> notation: >> >> m=audio ... >> a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... >> >> In this case, how do I specify that I am support two >> different schemes: >> "mikey" and "magic"? >> >> Is this going to be a single m= line >> >> m=audio ... >> a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... >> a=key-mgmt:magic data=jhas84hjkH9hjkSaDH38... >> >> which means that the key-mgmt attributes implicitly carries the >> semantics that the intersection of the algorithms is constructed >> and, in the offer/answer case, the answerer picks the one to use. >> >> Or, do I allow only exactly one key-mgmt attribute per m= line >> or session, use two a number media lines and group those somehow? >> >> Or shall only one be allowed at all and the initiator may need to >> try one by one? >> >> In either case, the spec needs to specify whether the initiator >> what the intended outcome is. I assume that non-availability >> of the requested key management protocol at the receiver will lead >> to a rejection of the offer? Or is "none" an acceptable outcome? >> This also needs to be specified. >> >> Of course, making the key management negotiable brings up the >> issues of bidding down attacks that we had in the context of SIP >> security. >> >> Regardless of the syntactical representation, this problem needs >> to be addressed. > >Good point. I think that the best approach will be that the offerer >include only one key mgmt suggestion in the first offer. If the >answerer does not support the suggested protocol, it should in its >response, indicate the protocols supported by including a key mgmt >attribute with the name of the protocol(s) supported (but no data >in it). I will include these kind of considerations in the next >version of the draft. Right, but doing this gets us into difficulties with the underlying state machine. What would have been an offer-answer with a set of key exchange protocols specified in the initial offer, now needs multiple round-trips. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 15 23:58:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14609 for ; Mon, 15 Apr 2002 23:58:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02946; Mon, 15 Apr 2002 23:54:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02913 for ; Mon, 15 Apr 2002 23:53:59 -0400 (EDT) Received: from io.luxxon.com ([65.162.241.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14577 for ; Mon, 15 Apr 2002 23:53:54 -0400 (EDT) Received: from CHARON (dhcp-000-177.luxxon.com [192.168.0.177]) by io.luxxon.com (8.11.3/8.11.3) with SMTP id g3G3rV916728 for ; Mon, 15 Apr 2002 20:53:31 -0700 (PDT) From: "Josh Perfetto" To: Date: Mon, 15 Apr 2002 20:50:59 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Grouping of media lines in SDP draft Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hello, In the recent draft, , which I believe was recently submitted to become an RFC, semantics for stream selection (i.e. where the same stream exists in multiple formats, to be chosen by the player) seems almost purposely ignored. Was that the case (perhaps because this is to be addressed by SDPng?). Or is there another standardized way to do this? -Josh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 05:53:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28070 for ; Tue, 16 Apr 2002 05:53:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01642; Tue, 16 Apr 2002 05:51:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA01611 for ; Tue, 16 Apr 2002 05:51:00 -0400 (EDT) Received: from wtnserver (80-25-218-178.uc.nombres.ttd.es [80.25.218.178]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28040 for ; Tue, 16 Apr 2002 05:50:55 -0400 (EDT) Received: from EI2 by wtnserver with SMTP (MDaemon.v3.1.2.R) for ; Sun, 14 Apr 2002 22:37:09 +0200 From: "The Financial News" To: mmusic@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf"; MIME-Version: 1.0 Date: Sun, 14 Apr 2002 22:36:33 +0200 X-Priority: 3 X-Library: Indy 8.0.22 X-MDRcpt-To: mmusic@ietf.org X-Return-Path: newsletters@the-financial-news.com X-MDaemon-Deliver-To: mmusic@ietf.org Reply-To: newsletters@the-financial-news.com Message-ID: Subject: [MMUSIC] Production Mini-plants in mobile containers. Co-investment Program Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Financial News, April 2002 Production Mini-plants in mobile containers. Co-investment Program =22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile=20containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring,=20piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22 More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework,=20Sheeting for Roofing, Ceilings and Fa=E7ades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups,=20Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material,=20Hypodermic Syringes, Hemostatic Clamps, etc.=20 Science Network has started a process of Co-investment for the installation of small Assembly plants to manufacture in series the Mini-plants of portable=20production on the site, region or country where they may be required. One of the most relevant features is the fact that these plants will be connected to the World=20Trade System (WTS) with access to more than 50 million raw materials, products and services and automatic transactions for world trade. Because of financial reasons, involving cost and social impact, the right thing to do is to set up assembly plants in the same countries and regions, using local=20resources (labor, some equipment, etc.) For more information: Mini-plants in mobile containers By Steven P. Leibacher, The Financial News, Editor Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion =22...Science Network suministrara a paises y regiones en vias de desarrollo la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-plantas de=20produccion en contenedores moviles (40-foot). El sistema de mini-plantas esta dise=F1ado de forma que todas las maquinas de produccion van instaladas fijas=20sobre la propia plataforma del contenedor, con el cableado, tuberias e instalaciones; es decir, completamente equipadas... y a partir de ese momento est=E1n listas=20para producir.=22=20 Mas de 700 sistemas de produccion portatil: Panaderias, Producci=F3n de clavos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvado de=20hierro para armaduras de construccion, Lamina perfilada para cubiertas, techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Menaje de=20polipropileno inyectado, Piezas de melamina prensada (vasos, platos, tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldada para la=20construccion, Bolsas y envases de plastico, Unidades moviles de asistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemostaticas, etc.) Science Network ha puesto en marcha un proceso de Co-inversion para la instalacion de peque=F1as Plantas ensambladoras para fabricar en serie las Mini-plantas=20de produccion portatil, en el lugar, region o pais que lo necesite. Una de las caracter=EDsticas relevantes es el hecho de que dichas plantas quedaran conectadas al=20Sistema del Comercio Mundial (WTS) con acceso a mas de 50 millones de mercancias, materia primas, productos, servicios y las operaciones automaticas de=20comercio internacional.=20 Resulta obvio que por razones economicas, de costes y de impacto social, lo apropiado es instalar plantas ensambladoras en los mismos paises y regiones asi=20como utilizar los recursos locales (mano de obra, ciertos equipamientos, etc.) Para recibir mas infromacion: Mini-plantas de produccion en contenedores moviles Steven P. Leibacher, The Financial News, Editor ------------------------------------------------------------------------- If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor =A9 2002 The Financial News. All rights reserved. --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The Financial News, April 2002

Production Mini-plants in mobile containers. Co-investment Program

=22...Science Network will supply to countries and developing regions the technology and the necessary support for the production in series of Mini-plants in mobile containers (40-foot). The Mini-plant system is designed in such a way that all the production machinery is fixed on the platform of the container, with all wiring, piping, and installation parts; that is to say, they are fully equipped... and the mini-plant is ready for production.=22

More than 700 portable production systems: Bakeries, Steel Nails, Welding Electrodes, Tire Retreading, Reinforcement Bar Bending for Construction Framework, Sheeting for Roofing, Ceilings and Façades, Plated Drums, Aluminum Buckets, Injected Polypropylene Housewares, Pressed Melamine Items (Glasses, Cups, Plates, Mugs, etc.), Mufflers, Construction Electrically Welded Mesh, Plastic Bags and Packaging, Mobile units of medical assistance, Sanitary Material, Hypodermic Syringes, Hemostatic Clamps, etc.

Science Network has started a process of Co-investment for the installation of small Assembly plants to manufacture in series the Mini-plants of portable production on the site, region or country where they may be required. One of the most relevant features is the fact that these plants will be connected to the World Trade System (WTS) with access to more than 50 million raw materials, products and services and automatic transactions for world trade.

Because of financial reasons, involving cost and social impact, the right thing to do is to set up assembly plants in the same countries and regions, using local resources (labor, some equipment, etc.)

For more information: Mini-plants in mobile containers

By Steven P. Leibacher, The Financial News, Editor


Mini-plantas de produccion en contenedores moviles. Programa de Co-inversion

=22...Science Network suministrara a paises y regiones en vias de desarrollo la tecnologia y el apoyo necesario para la fabricacion en serie de Mini-plantas de produccion en contenedores moviles (40-foot). El sistema de mini-plantas esta diseñado de forma que todas las maquinas de produccion van instaladas fijas sobre la propia plataforma del contenedor, con el cableado, tuberias e instalaciones; es decir, completamente equipadas... y a partir de ese momento están listas para producir.=22

Mas de 700 sistemas de produccion portatil: Panaderias, Producción de clavos de acero, Electrodos para soldadura, Recauchutado de neumaticos, Curvado de hierro para armaduras de construccion, Lamina perfilada para cubiertas, techos y cerramientos de fachada, Bidones de chapa, Cubos de aluminio, Menaje de polipropileno inyectado, Piezas de melamina prensada (vasos, platos, tazas, cafeteras, etc.) Silenciadores para vehiculos, Malla electrosoldada para la construccion, Bolsas y envases de plastico, Unidades moviles de asistencia medica, Material sanitario (jeringas hipodermicas, Pinzas hemostaticas, etc.)

Science Network ha puesto en marcha un proceso de Co-inversion para la instalacion de pequeñas Plantas ensambladoras para fabricar en serie las Mini-plantas de produccion portatil, en el lugar, region o pais que lo necesite. Una de las características relevantes es el hecho de que dichas plantas quedaran conectadas al Sistema del Comercio Mundial (WTS) con acceso a mas de 50 millones de mercancias, materia primas, productos, servicios y las operaciones automaticas de comercio internacional.

Resulta obvio que por razones economicas, de costes y de impacto social, lo apropiado es instalar plantas ensambladoras en los mismos paises y regiones asi como utilizar los recursos locales (mano de obra, ciertos equipamientos, etc.)

Para recibir mas infromacion: Mini-plantas de produccion en contenedores moviles

Steven P. Leibacher, The Financial News, Editor

-------------------------------------------------------------------------
If you received this in error or would like to be removed from our list, please return us indicating: remove or un-subscribe in 'subject' field, Thanks. Editor
© 2002 The Financial News. All rights reserved.

 --=_NextPart_2rfkindysadvnqw3nerasdf-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 07:28:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29362 for ; Tue, 16 Apr 2002 07:28:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05893; Tue, 16 Apr 2002 07:27:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA05858 for ; Tue, 16 Apr 2002 07:27:04 -0400 (EDT) Received: from aifhs8.alcatel.fr ([194.133.58.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29354 for ; Tue, 16 Apr 2002 07:27:01 -0400 (EDT) From: Juan-Carlos.Rojas@alcatel.fr Received: from frmail25.netfr.alcatel.fr (frmail25.netfr.alcatel.fr [155.132.182.155]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id NAA22206; Tue, 16 Apr 2002 13:26:00 +0200 (MET DST) Subject: Re: [MMUSIC] SDP(ng)&QoS To: "Andreas Kassler" Cc: suresh.leroy@alcatel.be, Date: Tue, 16 Apr 2002 13:25:58 +0200 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL25/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 04/16/2002 13:25:59 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hello all, End of February, ETSI organized a workshop on "QoS in Next Generation Networks", where the need of QoS negotiation and control at the session/application level was raised several times. You can find the presentations at the following url: http://www.etsi.org/frameset/home.htm?/QOSWORKSHOP/ Take a look also on the last presentation "Discussion and Conclusions" Maybe this can be used as input to our work in mmusic. Best regards Juan Carlos _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 11:36:44 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08459 for ; Tue, 16 Apr 2002 11:36:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23091; Tue, 16 Apr 2002 11:28:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23057 for ; Tue, 16 Apr 2002 11:28:55 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08220 for ; Tue, 16 Apr 2002 11:28:44 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3GFSl3G019072 for ; Tue, 16 Apr 2002 17:28:47 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Apr 16 17:28:46 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Apr 2002 17:18:19 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D0110DBF4@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (ERA)" To: "'Colin Perkins'" , "Fredrik Lindholm (ERA)" Cc: "'Joerg Ott'" , mmusic@ietf.org Subject: RE: [MMUSIC] Key mgmt extensions "blob" discussion Date: Tue, 16 Apr 2002 17:26:20 +0200 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi Colin > -----Original Message----- > From: Colin Perkins [mailto:csp@isi.edu] > Sent: den 15 april 2002 23:53 > To: Fredrik Lindholm (ERA) > Cc: 'Joerg Ott'; mmusic@ietf.org; Elisabetta Carrara (ERA) > Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion > > > --> "Fredrik Lindholm (ERA)" writes: > > > >> > >> Since we have talked about potential further key > management protocols: > >> the draft talks about this but does not specify how to > negotiate the > >> key management protocol: > >> > >> Let's assume (without stating consent here) that we use > the following > >> notation: > >> > >> m=audio ... > >> a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... > >> > >> In this case, how do I specify that I am support two > >> different schemes: > >> "mikey" and "magic"? > >> > >> Is this going to be a single m= line > >> > >> m=audio ... > >> a=key-mgmt:mikey data=SJKHkdakhjfkjDSY083u... > >> a=key-mgmt:magic data=jhas84hjkH9hjkSaDH38... > >> > >> which means that the key-mgmt attributes implicitly carries the > >> semantics that the intersection of the algorithms is constructed > >> and, in the offer/answer case, the answerer picks the one to use. > >> > >> Or, do I allow only exactly one key-mgmt attribute per m= line > >> or session, use two a number media lines and group those somehow? > >> > >> Or shall only one be allowed at all and the initiator may need to > >> try one by one? > >> > >> In either case, the spec needs to specify whether the initiator > >> what the intended outcome is. I assume that non-availability > >> of the requested key management protocol at the receiver will lead > >> to a rejection of the offer? Or is "none" an acceptable outcome? > >> This also needs to be specified. > >> > >> Of course, making the key management negotiable brings up the > >> issues of bidding down attacks that we had in the context of SIP > >> security. > >> > >> Regardless of the syntactical representation, this problem needs > >> to be addressed. > > > >Good point. I think that the best approach will be that the offerer > >include only one key mgmt suggestion in the first offer. If the > >answerer does not support the suggested protocol, it should in its > >response, indicate the protocols supported by including a key mgmt > >attribute with the name of the protocol(s) supported (but no data > >in it). I will include these kind of considerations in the next > >version of the draft. > > Right, but doing this gets us into difficulties with the > underlying state > machine. What would have been an offer-answer with a set of > key exchange > protocols specified in the initial offer, now needs multiple > round-trips. > > Colin > ok, we see. It is not a problem for us to place the set of key management protocols in the offer if so is wanted, however we did not want to do that because of the impact it has, e.g. the size of the SIP message (note also, a certain fraction of the key management data can't be efficiently compressed). Hence, if you want the set approach, we would add a recommendation on the inclusion of only one key management protocol in the offer. cheers /E _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 11:47:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08911 for ; Tue, 16 Apr 2002 11:47:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24211; Tue, 16 Apr 2002 11:42:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24174 for ; Tue, 16 Apr 2002 11:42:33 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08640 for ; Tue, 16 Apr 2002 11:42:28 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3GFgNY00769; Tue, 16 Apr 2002 11:42:23 -0400 Message-Id: <200204161542.g3GFgNY00769@chiron.nge.isi.edu> To: "Elisabetta Carrara (ERA)" cc: "Fredrik Lindholm (ERA)" , "'Joerg Ott'" , mmusic@ietf.org Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion In-Reply-To: Your message of "Tue, 16 Apr 2002 17:26:20 +0200." <4E85E49D1F0CBF4F96EA08E335750D7D0110DBF4@Esealnt877.al.sw.ericsson.se> Date: Tue, 16 Apr 2002 11:42:23 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --> "Elisabetta Carrara (ERA)" writes: ... >> >Good point. I think that the best approach will be that the offerer >> >include only one key mgmt suggestion in the first offer. If the >> >answerer does not support the suggested protocol, it should in its >> >response, indicate the protocols supported by including a key mgmt >> >attribute with the name of the protocol(s) supported (but no data >> >in it). I will include these kind of considerations in the next >> >version of the draft. >> >> Right, but doing this gets us into difficulties with the >> underlying state >> machine. What would have been an offer-answer with a set of >> key exchange >> protocols specified in the initial offer, now needs multiple >> round-trips. > >ok, we see. It is not a problem for us to place the set of >key management protocols in the offer if so is wanted, >however we did not want to do that because of the impact it has, >e.g. the size of the SIP message (note also, a certain fraction of >the key management data can't be efficiently compressed). >Hence, if you want the set approach, we would add a recommendation >on the inclusion of only one key management protocol in the offer. I don't know the correct approach, since I don't know the operation of the key exchange protocols. Is it sensible to enumerate multiple protocols? Or is it better to send one, and figure out how to restart the negotiation if that is unsuitable? Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 12:24:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14353 for ; Tue, 16 Apr 2002 12:24:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26995; Tue, 16 Apr 2002 12:17:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26960 for ; Tue, 16 Apr 2002 12:17:16 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13496 for ; Tue, 16 Apr 2002 12:17:10 -0400 (EDT) Received: from mira-sjc5-6.cisco.com (IDENT:mirapoint@mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g3GGGcOQ022365; Tue, 16 Apr 2002 09:16:38 -0700 (PDT) Received: from mbaugher-w2k1.cisco.com ([10.34.251.92]) by mira-sjc5-6.cisco.com (Mirapoint) with SMTP id ABL68889; Tue, 16 Apr 2002 09:14:38 -0700 (PDT) Message-Id: <4.3.2.7.2.20020416091333.04602da8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Apr 2002 09:15:23 -0700 To: Colin Perkins From: Mark Baugher Subject: Re: [MMUSIC] Key mgmt extensions "blob" discussion Cc: mmusic@ietf.org In-Reply-To: <200204161542.g3GFgNY00769@chiron.nge.isi.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org At 11:42 AM 4/16/2002 -0400, Colin Perkins wrote: >--> "Elisabetta Carrara (ERA)" writes: >... > >> >Good point. I think that the best approach will be that the offerer > >> >include only one key mgmt suggestion in the first offer. If the > >> >answerer does not support the suggested protocol, it should in its > >> >response, indicate the protocols supported by including a key mgmt > >> >attribute with the name of the protocol(s) supported (but no data > >> >in it). I will include these kind of considerations in the next > >> >version of the draft. > >> > >> Right, but doing this gets us into difficulties with the > >> underlying state > >> machine. What would have been an offer-answer with a set of > >> key exchange > >> protocols specified in the initial offer, now needs multiple > >> round-trips. > > > >ok, we see. It is not a problem for us to place the set of > >key management protocols in the offer if so is wanted, > >however we did not want to do that because of the impact it has, > >e.g. the size of the SIP message (note also, a certain fraction of > >the key management data can't be efficiently compressed). > >Hence, if you want the set approach, we would add a recommendation > >on the inclusion of only one key management protocol in the offer. > >I don't know the correct approach, since I don't know the operation of the >key exchange protocols. Is it sensible to enumerate multiple protocols? Or >is it better to send one, and figure out how to restart the negotiation if >that is unsuitable? I think the latter. The former is yet to be invented AFAIK. Mark >Colin > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 18:16:00 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27428 for ; Tue, 16 Apr 2002 18:16:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17443; Tue, 16 Apr 2002 18:10:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17410 for ; Tue, 16 Apr 2002 18:10:57 -0400 (EDT) Received: from ns1.ottawa.alcatel.ca (ns1.ottawa.alcatel.ca [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26954 for ; Tue, 16 Apr 2002 18:10:52 -0400 (EDT) Received: (qmail 26233 invoked from network); 16 Apr 2002 21:56:59 -0000 Received: from portal.ottawa.alcatel.ca (HELO mx1.ca.alcatel.com) (192.75.23.76) by ns1.ottawa.alcatel.ca with SMTP; 16 Apr 2002 21:56:59 -0000 Received: (qmail 8970 invoked from network); 16 Apr 2002 22:12:47 -0000 Received: (ofmipd 138.120.45.50); 16 Apr 2002 22:12:25 -0000 Date: 16 Apr 2002 18:10:46 -0400 Message-ID: <3CBCA166.43E0248D@alcatel.com> From: "Ian Leighton" To: "mmusic@ietf.org" X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RFC3108 Discrepency Between Text and Grammar Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi The text in RFC3108 section 2.5 indicate that the '$' can used in place of an SDP parameter value as a wildcard to indicate that the recipient should select a value. This does not seem to be supported in the syntax described in section 9. Does anyone know which takes precedence; the grammar in section 9 or the text in section 2.5? Any comments/corrections/clarifications would be appreciated. Regards Ian Leighton _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 16 18:49:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00342 for ; Tue, 16 Apr 2002 18:49:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18961; Tue, 16 Apr 2002 18:48:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18928 for ; Tue, 16 Apr 2002 18:48:17 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00194 for ; Tue, 16 Apr 2002 18:48:14 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3GMlQNo027577; Tue, 16 Apr 2002 15:47:26 -0700 (PDT) Received: from RKUMARW2K (dhcp-128-107-141-83.cisco.com [128.107.141.83]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id PAA18444; Tue, 16 Apr 2002 15:47:42 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Ian Leighton" , Subject: RE: [MMUSIC] RFC3108 Discrepancy Between Text and Grammar Date: Tue, 16 Apr 2002 15:47:42 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3CBCA166.43E0248D@alcatel.com> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Your interpretation of Section 2.5 is incorrect. The statement in Section 2.5 is not a blanket permission to use '$' wherever one wants to. It merely describes what '$' means where and if it is used. The ABNF in Section 9 does show the any '$' wildcard (in all those instances where it is useful. Examples: netttype, at various places in the ATM address, at various places in the virtual circuit connection ID etc. Also, '$' use is described in various sections of RFC 3108, along with examples. You should use the ABNF in section 9, and the text and examples in the various sections of RFC 3108 to determine where the use of a '$' wildcard is appropriate. I hope this is clear. Rajesh > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Ian Leighton > Sent: Tuesday, April 16, 2002 3:11 PM > To: mmusic@ietf.org > Subject: [MMUSIC] RFC3108 Discrepency Between Text and Grammar > > > Hi > > The text in RFC3108 section 2.5 indicate that the '$' can used in place > of > an SDP parameter value as a wildcard to indicate that the recipient > should > select a value. This does not seem to be supported in the syntax > described > in section 9. > > Does anyone know which takes precedence; the grammar in section 9 or the > > text in section 2.5? > > Any comments/corrections/clarifications would be appreciated. > > Regards > Ian Leighton > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 17 09:29:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16950 for ; Wed, 17 Apr 2002 09:29:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07471; Wed, 17 Apr 2002 09:01:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07440 for ; Wed, 17 Apr 2002 09:01:14 -0400 (EDT) Received: from ns1.ottawa.alcatel.ca (ns1.ottawa.alcatel.ca [192.75.23.67]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16276 for ; Wed, 17 Apr 2002 09:01:10 -0400 (EDT) Received: (qmail 1278 invoked from network); 17 Apr 2002 12:47:23 -0000 Received: from portal.ottawa.alcatel.ca (HELO mx1.ca.alcatel.com) (192.75.23.76) by ns1.ottawa.alcatel.ca with SMTP; 17 Apr 2002 12:47:23 -0000 Received: (qmail 23150 invoked from network); 17 Apr 2002 13:03:11 -0000 Received: (ofmipd 138.120.45.50); 17 Apr 2002 13:02:49 -0000 Date: 17 Apr 2002 09:01:10 -0400 Message-ID: <3CBD7216.20F6E3AE@alcatel.com> From: "Ian Leighton" To: "mmusic@ietf.org" X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RFC3108 $ in c= line not supported by $ in m= line Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi All Section 5.3 of RFC3108 indicates that the parameter of the c= line can be encoded as $. This section indicates that the purpose of the $ is to allow a selection if a node interfaces to multiple networks. Section 5.5.2 and the grammar of section 9 indicate that the parameters of the m= line is NOT allowed to be encoded as $. Is it possible to indicate via the rfc3108 SDP that the recipient choose the c= line and also choose the corresponding m= line parameter? Any comments/corrections/clarifications would be appreciated. Regards Ian _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 17 10:19:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19395 for ; Wed, 17 Apr 2002 10:19:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10719; Wed, 17 Apr 2002 09:55:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10684 for ; Wed, 17 Apr 2002 09:55:39 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17859; Wed, 17 Apr 2002 09:55:34 -0400 (EDT) Message-Id: <200204171355.JAA17859@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 17 Apr 2002 09:55:34 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-comedia-02.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Connection-Oriented Media Transport in SDP Author(s) : D. Yon Filename : draft-ietf-mmusic-sdp-comedia-02.txt Pages : 14 Date : 16-Apr-02 This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines two new protocol identifiers: TCP and TLS. It also defines the syntax and semantics for an SDP 'direction' attribute that describes the connection setup procedure. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-comedia-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-sdp-comedia-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-sdp-comedia-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: <20020416152552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-comedia-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-comedia-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020416152552.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 18 11:58:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12012 for ; Thu, 18 Apr 2002 11:58:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08264; Thu, 18 Apr 2002 11:52:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08224 for ; Thu, 18 Apr 2002 11:52:27 -0400 (EDT) Received: from gw-us4.philips.com (gw-us4.philips.com [63.114.235.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11795; Thu, 18 Apr 2002 11:52:22 -0400 (EDT) From: qiong-stan.li@philips.com Received: from smtpscan-us1.philips.com (localhost.philips.com [127.0.0.1]) by gw-us4.philips.com with ESMTP id KAA27082; Thu, 18 Apr 2002 10:52:26 -0500 (CDT) (envelope-from qiong-stan.li@philips.com) Received: from smtpscan-us1.philips.com(167.81.233.25) by gw-us4.philips.com via mwrap (4.0a) id xma027079; Thu, 18 Apr 02 10:52:26 -0500 Received: from smtprelay-us1.philips.com (localhost [127.0.0.1]) by smtpscan-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA27943; Thu, 18 Apr 2002 10:52:25 -0500 (CDT) Received: from arj001soh.diamond.philips.com (amsoh01.diamond.philips.com [161.88.79.212]) by smtprelay-us1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA28100; Thu, 18 Apr 2002 10:52:24 -0500 (CDT) To: avt@ietf.org, mmusic@ietf.org X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 18 Apr 2002 11:02:10 -0500 X-MIMETrack: Serialize by Router on arj001soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 18/04/2002 10:55:23, Serialize complete at 18/04/2002 10:55:23 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0057B52585256B9F_=" Subject: [MMUSIC] Looking for implementation of RFC 2733 - RTP payload type for FEC Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multipart message in MIME format. --=_alternative 0057B52585256B9F_= Content-Type: text/plain; charset="us-ascii" I am looking for an open-source library that includes the implementation of RFC 2733 and FEC codecs. Could anyone provide a link? Any related information is highly appreciated. Thanks in advance. _____________________________________ Stan Li, Ph.D Philips Research USA --=_alternative 0057B52585256B9F_= Content-Type: text/html; charset="us-ascii"
I am looking for an open-source library that includes the implementation of RFC 2733 and FEC codecs. Could anyone provide  a link? Any related information is highly appreciated.

Thanks in advance.

_____________________________________
Stan Li, Ph.D
Philips Research USA
 --=_alternative 0057B52585256B9F_=-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 18 15:01:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19559 for ; Thu, 18 Apr 2002 15:01:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25153; Thu, 18 Apr 2002 14:59:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA25118 for ; Thu, 18 Apr 2002 14:59:40 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19455 for ; Thu, 18 Apr 2002 14:59:36 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g3IIx801000889; Thu, 18 Apr 2002 11:59:08 -0700 (PDT) Received: from RKUMARW2K (rtp-vpn2-306.cisco.com [10.82.241.50]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA02348; Thu, 18 Apr 2002 11:59:06 -0700 (PDT) Reply-To: From: "Rajesh Kumar" To: "Ian Leighton" , Subject: RE: [MMUSIC] RFC3108 $ in c= line not supported by $ in m= line Date: Thu, 18 Apr 2002 11:59:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <3CBD7216.20F6E3AE@alcatel.com> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Ian, RFC 2327 states: An announcement consists of a session-level section followed by zero or more media-level sections. The m line is not mandatory. So you can wildcard the network type and omit the 'm' line. This is how you can ask the recipient to select both network type and transport. There is another means. You can set the transport and format to "-" each. Here is what RFC 3108 says about the use of "-": A "-" value indicates that it is not necessary to specify the value of the parameter in the SDP description because this parameter .... can be known from another source such as ..., another SDP descriptor or another part of the same SDP descriptor. For an example, search for the string "m=audio $ - -" in RFC 3108. The other SDP descriptor can, in this case, be the recipient's response which includes the network type, transport and formats. In this context, note the following RFC3108 ABNF: transport-fmts = generic-transport-fmts / known-transport-fmts / "- -" Rajesh > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Ian Leighton > Sent: Wednesday, April 17, 2002 6:01 AM > To: mmusic@ietf.org > Subject: [MMUSIC] RFC3108 $ in c= line not supported by $ in m= line > > > Hi All > > Section 5.3 of RFC3108 indicates that the parameter of the > c= line can be encoded as $. This section indicates that the purpose of > the $ is to allow a selection if a node interfaces to multiple networks. > > Section 5.5.2 and the grammar of section 9 indicate that the > parameters of the m= line is NOT allowed to be encoded as $. Right, but there is the following possibility: "-" indicated a don't care. > > Is it possible to indicate via the rfc3108 SDP that the recipient choose > the c= line and also choose the corresponding m= line > parameter? > > Any comments/corrections/clarifications would be appreciated. > > Regards > Ian > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 18 16:29:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21866 for ; Thu, 18 Apr 2002 16:29:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29833; Thu, 18 Apr 2002 16:19:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA29796 for ; Thu, 18 Apr 2002 16:19:19 -0400 (EDT) Received: from thepolyglots.com (scz201.zuper.net [166.114.165.201]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21672 for ; Thu, 18 Apr 2002 16:19:06 -0400 (EDT) Message-Id: <200204182019.QAA21672@ietf.org> From: "Polyglots" To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 18 Apr 2002 16:19:19 -0700 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [MMUSIC] Haben Sie ein Buch geschrieben? Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Haben Sie ein Buch geschrieben? Suchen Sie ein Verleger? Wir können Ihnen helfen Ihr Buch auf Deutsch, Englisch und Spanish gleichzeiting zu veröffentlichen. Für mehrer Einzelheiten schreiben Sie bitte an languages@thepolyglots.com an Hern Paz _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 18 23:30:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00948 for ; Thu, 18 Apr 2002 23:30:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23886; Thu, 18 Apr 2002 23:23:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA23854 for ; Thu, 18 Apr 2002 23:23:09 -0400 (EDT) From: owner-mmusic@ns.ietf.org Received: from www.xinaogroup.com ([203.212.5.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00720 for ; Thu, 18 Apr 2002 23:23:02 -0400 (EDT) Received: from smtp0301.mail.yahoo.com ([218.24.129.153]) by www.xinaogroup.com (8.11.6/8.8.7) with SMTP id g3J3NTr24030; Fri, 19 Apr 2002 11:23:30 +0800 Message-Id: <200204190323.g3J3NTr24030@www.xinaogroup.com> Date: Fri, 19 Apr 2002 11:23:44 +0800 X-Priority: 3 To: mmusic@idirect.com CC: mmusic@ietf.org, mmusic@indonesia.crosswinds.net, mmusic@jersey.net, mmusic@jump.net Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Feeling Old? We Can Help! Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit


Hello, mmusic@idirect.com,

As seen on NBC, CBS, CNN, and even Oprah! The health discovery that actually reverses aging while burning fat, without dieting or exercise! This proven discovery has even been reported on by the New England Journal of Medicine. Forget aging and dieting forever! And it's Guaranteed!


Click here

Would you like to lose weight while you sleep!
No dieting!
No hunger pains!
No Cravings!
No strenuous exercise!
Change your life forever!

1.Body Fat Loss 82% improvement.
2.Wrinkle Reduction 61% improvement.
3.Energy Level 84% improvement.
4.Muscle Strength 88% improvement.
5.Sexual Potency 75% improvement.
6.Emotional Stability 67% improvement.
7.Memory 62% improvement.

100% GUARANTEED!

 

You are receiving this email as a subscriber
to the Opt-In America Mailing List.
To remove yourself from all related maillists,
just Click Here

_______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 19 07:24:56 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16137 for ; Fri, 19 Apr 2002 07:24:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02645; Fri, 19 Apr 2002 07:22:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02589 for ; Fri, 19 Apr 2002 07:22:41 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15935; Fri, 19 Apr 2002 07:22:39 -0400 (EDT) Message-Id: <200204191122.HAA15935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:22:39 -0400 Subject: [MMUSIC] I-D ACTION:draft-prandolini-mmusic-jpip-requirements-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : JPIP Requirements and Profiles Author(s) : R. Prandolini, R. Clark, S. Houchin Filename : draft-prandolini-mmusic-jpip-requirements-00.txt Pages : 7 Date : 18-Apr-02 This document describes the requirements for an intelligent protocol for serving JPEG 2000 compressed image and metadata (JPIP). This document represents version 2 of the requirements and profiles of the JPIP standard (ISO/IEC 15444-9) found in document WG1N2522 of ISO/IEC JTC1/SC29/WG1 (the JPEG committee). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-prandolini-mmusic-jpip-requirements-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-prandolini-mmusic-jpip-requirements-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-prandolini-mmusic-jpip-requirements-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: <20020418140927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-prandolini-mmusic-jpip-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-prandolini-mmusic-jpip-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140927.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 19 20:03:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22005 for ; Fri, 19 Apr 2002 20:03:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18708; Fri, 19 Apr 2002 20:02:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA18669 for ; Fri, 19 Apr 2002 20:02:06 -0400 (EDT) Received: from nmh.informatik.uni-bremen.de (root@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21743; Fri, 19 Apr 2002 20:02:02 -0400 (EDT) Received: from tzi.uni-bremen.de (root@localhost [127.0.0.1]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g3K01iR07988; Sat, 20 Apr 2002 02:01:44 +0200 (MEST) Message-ID: <3CC0B019.6D08BEB4@tzi.uni-bremen.de> Date: Sat, 20 Apr 2002 02:02:33 +0200 From: Joerg Ott X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: minutes@ietf.org, mmusic@ietf.org CC: csp@isi.edu Content-Type: multipart/mixed; boundary="------------FD7F38C243945B10DAE87DB0" Subject: [MMUSIC] MMUSIC Minutes Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------FD7F38C243945B10DAE87DB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, please find attached the minutes of the MMUSIC WG. The slides are available from http://www.dmn.tzi.org/ietf/mmusic. In particular, collections of all the slides are available at http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-ppt.zip http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-pdf.zip http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-ps.zip for the PPT (without the SDP presentation), PDF, and PS versions. Thanks, Colin & Joerg --------------FD7F38C243945B10DAE87DB0 Content-Type: text/plain; charset=us-ascii; name="53-mmusic-minutes.txt" Content-Disposition: inline; filename="53-mmusic-minutes.txt" Content-Transfer-Encoding: 7bit Multiparty Multimedia Session Control WG (MMUSIC) ================================================= Wednesday, March 20 at 0900-1130 -------------------------------- CHAIRS: Joerg Ott Colin Perkins NOTES: Tom Taylor, Colin Perkins EDITED: Joerg Ott SLIDES: http://www.dmn.tzi.org/ietf/mmusic/ The MMUSIC WG met once at the 53rd IETF. The meeting was attended by some 150 participants. After routine announcements the chairs presented the proposed agenda which was accepted. Then they announced a joint lunch discussion for interested parties from MMUSIC and SIPPING on the general topic of conferencing on the same day right after the MMUSIC session. Furthermore, a lunch discussion is to take place on Thursday on RTSP. Agenda Bashing and Status Update -------------------------------- Presenters: chairs Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs presented a brief status update. Work on the following drafts has been finished and they have been or about about to be sent to the IESG: - draft-ietf-mmusic-fid-06.txt - draft-andreasen-mmusic-sdp-simcap-05.txt - draft-ietf-mmusic-sdp4nat-02.txt - draft-ietf-mmusic-sdp-offer-answer-02.txt - draft-ietf-mmusic-sdp-ipv6-03.txt The revised charter of the MMUSIC WG has been approved, with milestones through July and a review for continuation in the summer. Work regarding most of the currently defined milestones is still on schedule. The submission of therevised SDP spec and the SDPng motivations are late. SDP key management is in yellow status, not likely going to be on time. Revised RTSP Specification -------------------------- Presenters: Rob Lanphier , Magnus Westerlund Drafts: draft-ietf-mmusic-rfc2326bis-00.txt Slides: 53-mmusic-rtsp.{ppt,pdf,ps} The authors are working to go to Draft Standard. Originally submission of the revised spec was planned to be done May 2002. However, there is only a 30% chance of finishing specification by then. There is a delay on interop documentation. Authors are working on moving more complex/less implemented features out of core specification and into extensions. The design team has been holding open biweekly teleconferences since January 2002. So far ~68 bugs and 8 feature requests have been filed. Of the bugs, 20 have been closed, 5 have been classified as "large tasks", and most of the others have yet to be addressed. The feature requests have not been discussed in detail. Resolution of the following big issues has reached teleconference consensus, which the team would like the MMUSIC WG to confirm: * Clarification of aggregate/non-aggregate control - state machine has been reworked - removed automatic transition at end of clip - general sense that all transitions should be on the client side * Should we eliminate queued play? - tentative answer of the design team: yes * RECORD needs specification work from implementors - may drop for lack of participation * MUTE/UNMUTE proposal - replacing use of PAUSE for this purpose * Transport mode requirements - make support of persistent TCP mode required - non-persistent TCP mode required? (No, make optional and use SIP Supported: tag) * Registration of feature tags for optional features (need to audit the specification) Magnus Westerlund gave an overview of the simplified state machine. The model features separate non-aggregate and aggregate Ready and Play states. Transition between Initial, Non-Aggregate, and Aggregate modes can occur only when no media are playing out (i.e. in the Ready states). Question: Can resources be stranded if the server has no no automatic change of state after play? Rob responded: not too many resources are tied up at that point. The server can release resources specifically associated with the playout without changing state. So long as the client is there, the remaining resources will eventually be released. Queued play (multiple PLAY requests, with the server responsible for serializing them): makes the state machine much more complex. The proposal is to allow multiple ranges in PLAY as a substitute, to be specified as an extension to the core document. Henning Schulzrinne maintained that the Queued play mechanism does not really affect the state machine. Magnus replied that this was technically correct, but it raises other issues. Henning argued that removal from the core specification could remove functionality needed by every server. He was concerned that mapping of multiple ranges (the proposed substitute) might be difficult. This subject will be discussed further as part of Thursday's lunch meeting -- and subsequently on the list. RECORD: this is obviously a desirable feature, but implementors need to to contribute since the current mechanism is underspecified. One of the open questions is whether ANNOUNCE is required. If so, how does one pair the session ID with the announcement? Two people in the room identified themselves as candidates for this part of the work. The work is continuing by teleconferencing. Stephen Casner suggested that the current status might call for a Proposed Standard revision, allowing the group to finish interoperability testing in the ensuing 6 months. Henning Schulzrinne was concerned that this double effort might squander the energy of the participants and the IESG. Stephen clarified that the transition to Draft Standard would be procedural, requiring no revision to the specification itself. There is an urgent need to formulate a feature matrix. Volunteers were sought, but none were forthcoming at the meeting. MUTE/UNMUTE extension --------------------- Presenter: Aravind Narasimhan . Drafts: draft-sergent-rtsp-mute-00.txt Slides: 53-mmusic-rtsp-mute-unmute.{ppt,pdf,ps} The authors identify that RFC 2326 is ambiguous and incomplete regarding the implementation of features such as muting and unmuting individual media streams as well as a session as a whole. Particularly, aggregate/non-aggregate control interaction needs clarification. Currently, the PLAY and PAUSE methods are overloaded to achieve the desired functionality. The mute/unmute functionality seems an important (but optional) features. This feature specification has the support of the team at large, not just that of the authors. It fixes ambiguities and lack of completeness in RFC 2326. It is proposed to remove "mute" functionality from the core RTSP spec and turn it into an extension. As a result, won't be able to do pause of a single stream in an aggregately controlled presentation. The basic semantics of a new MUTE method are to temporarily suspend one stream while the presentation clock keeps running (so other streams can advance). The proposed UNMUTE method resumes delivery of a stream from current presentation NPT. In both methods, a Range: header (which must be open) is allowed to schedule MUTE commands. The authors also list a number of open issues to be addressed: * interation with queued PLAY, RECORD * UNMUTE response needs a Range header * what is the response to UNMUTE on an already UNMUTED stream? - 200 OK? 455 Method not valid in this state? Other? * effect on RTSP state machine if any? * IANA registration: "mute" options tag * definitions of terms, security considerations, acknowledgements. Humming indicates moderate support to take this up as a WG item with no one opposing. RTP Archiving, Delivery, and Playback extensions for SDP (RADPlay) ------------------------------------------------------------------ Presenter: Rob Lanphier Drafts: draft-lanphier-radplay-00.txt Slides: 53-mmusic-rtsp-radplay.{ppt,pdf,ps} The motivation for this proposal is to get around firewall blocking certain protocol traffic (such as media streaming). It enables HTTP-based delivery of RTP. The approach taken also solves numerous other problems including archiving, cache population, archive playback. The proposed mechanism defines a set of simple extensions to SDP: In addition to just providing the session description for one or more media streams as RTP session description(s), further attributes are defined that indicate the source file format of the media streams so that these can be retrieved (via download by means of e.g. HTTP) if setting up an RTSP/RTP-based media session does not succeed. Three extension attributes are proposed: a=srcfile -- URL for source media in on-demand playback a=dumpfile -- URL for "dump" of an individual stream a=dumpindex -- simple index to dumpfile In addition, the a=control can be used outside of RTSP session context to indicate SDP meta files. Rob showed an example featuring fallback from one possibility to the next. Melinda Shore commented that archiving is good, but violating firewall policy is not. We should resist proposals with that intent in the IETF. Henning Schulzrinne countered that the proposal was actually adapting to local policy, not bypassing it -- if streaming is not allowed, the proposal falls back to file transfer. It is easy to block the MIME type at firewall. This is a more explicit alternative to stealth approaches. Syntax comment: generalize to "alternate file" attribute. Rob responded that it was nice to have the tighter semantics presented, but the proposal was something to be discussed on list. The chairs' poll indicated reasonable support for doing this work as MMUSIC work item, with some opposition. Revised SDP spec ---------------- Presenter: Colin Perkins Drafts: draft-ietf-mmusic-sdp-new-06.txt Slides: 53-mmusic-sdp.{pdf,ps} The work on SDP has featured bug fixes. There have been two revisions since last meeting. Colin reviewed the changes in -05 and -06. To do: allow a=rtpmap to be a session-level attribute, as agreed on the list. Colin asked whether there should be a TTL parameter for IPv6 multicast. Gonzalo Camarillo noted that this parameter was removed from the IPv6 draft at IESG direction. Conclusion: it will be removed from text. Colin called for volunteers for interoperability testing. A few volunteers raised their hands. Keith Drage asked about the schedule for approval of the new document. 3GPP needs an RFC number for reference by June. Colin indicated that the schedule was constrained by interoperability testing. A viable alternative to meet 3G deadlines is not to go to Draft Standard right away but cycle at proposed. If going to draft is possible then this is the preferred approach. Key management with SDP ----------------------- Presenter: Fredrik Lindholm Drafts: draft-ietf-mmusic-kmgmt-ext-03.txt Slides: 53-mmusic-sdp-kmgmt-ext.{ppt,pdf,ps} The latest revision of the document has more added more rationale to text and has adopted the offer-answer model as basis for the key exchange. Furthermore, the ABNF has been updated to conform with latest SDP, RTSP. Scenarios and examples have been added. The following SDP extensions are proposed: keymgmt-prtcl = "keymgmt-prot:" prtcl-name prtcl-name = non-ws-string keymgmt-data = "keymgmt-data:" byte-string key-extra-auth = "keymgmt-auth:" byte-string For RTSP, additional extensions are required since SDP is not always passed between the peers when key management needs it: KeyMgmt = "KeyMgmt" ":" [stream-url] protocol data stream-url = "url" "=" url ";" protocol = "Prot" "=" token ";" data = "Data" "=" quoted-string Colin noted the philosophical issue of whether parameters should be opaque or whether instead the semantics should be more explicit. Henning Schulzrinne commented that explicit semantics make interoperability debugging easier. Martin Euchner queried the scope of intended application of the extensions, and was satisfied with Fredrik's response. He raised an issue with NAT passage. Fredrik agreed the receiver cannot authenticate a NATted port. One person spoke against explicit semantics, except for the authentication part. Another person foresaw issues with encryption validity if the blob is broken up: The length of the attributes might cause problems for the containing signalling. Also, offer-answer may be able to carry other key management protocols, but a change in the messaging model might be needed. There is also need to think of support for future key exchange protocols with differing numbers of message exchanges. Peter Barany expressed his preference for explicit semantics, reflecting discussion from the compression group. It is possible the static dictionary would be enhanced. Some people noted problems connected with this. Carsten Bormann noted that the SIP dictionary would be generated soon. The stability of naming of attributes is of interest -- changes affect efficiency. Christian Huitema asked if we should SDP-level encryption or S/MIME. What changes would there be if SDP were carried in S/MIME? The response was that this would be good if one can assume S/MIME is always used. Tom Taylor noted the potential impact of that assumption on Megaco, which carries SDP embedded within the protocol rather than as a separate body. Joerg Ott indicated that the WG should do an analysis of the implications of S/MIME. Further discussion on the list is needed to close on these issues. SDP for connection-oriented media --------------------------------- Presenters: David Yon provided a status update. The following Drafts: draft-ietf-mmusic-sdp-comedia-01.txt Slides: 53-mmusic-sdp-comedia.{ppt,pdf,ps} 53-mmusic-agenda.{ppt,pdf,ps} Work is proceeding on the next revision of the draft (-02). Changes to go into this draft include a new section on symmetric RTP/AVP and minor syntax changes to match SDP-new. There are still issues with the attribute direction:reuse and direction:both still have issues. Joerg Ott took over to present some proposals to resolve the issues that the current comedia model is somewhat inconsistent with the use of SDP for RTP streams. The issues as he summarized them derived from the following points of inconsistency between the comedia model and SDP use for RTP streams: TCP requires explicit setup/teardown as an extra step at the transport layer (while for UDP only local state is created but not shared at the transport layer). TCP connections are bi-directional but are created asymmetrically while this process is symmetric for RTP/UDP. There are other differences from UDP, but with this draft we are looking at transport capability as opposed to transport use. It is important that the basic SDP handling not be changed for comedia: session descriptions must be self-contained and, as for RTP/UDP, resending same SDP should cause no change in state. The WG came up with a list of requirements in December, but the topic died. Joerg presented that list, with one possible addition. He asked whether it is required to allow multiple TCP connections as part of a single media stream. Joerg noted that the requirements may differ for non-SIP use. The WG may want to limit the scope of the draft. Gonzalo Camarillo didn't think multiple TCP connections would work. However, there are other means for grouping. Joerg summed up: the WG needs to continue work toward a general solution, meeting the requirements one by one. He suggested a conceptual approach based on "primitives". SDP for voice-band data ----------------------- Presenters: Rajesh Kumar Drafts: draft-foster-mmusic-vbdformat-01.txt Slides: 53-mmusic-sdp-vbdformat.{ppt,pdf,ps} The draft proposes a new MIME type to distinguish voice-band encoded data (VBD) (e.g. low-speed modems). One parameter is specified to indicate the underlying coding (PCMU, G.726-32, etc.), another to indicate the data rate. The MIME type approach was taken in response to comments on an earlier approach. The underlying coding parameter is required because there is a requirement to associate VBD with the underlying encoding. Stephen Casner observed that the indirect approach to the definition of encoding seemed to be the wrong approach, because it hides the codec at a level below where implementors would expect). However, we can't provide the required fmtp parameters to existing formats. Colin Perkins saw two choices: use attributes, or add parameters to specific encodings. Stephen suggested that one could have a=vbd: 98 where the 98 is then mapped to VBD/8000. As an alternative: define PCMU-VBD etc. Henning Schulzrinne judged this latter the cleanest solution, but not generalizable to the next attribute. Stephen suggested the possible addition of an attribute like fmtp, but not encoding specific. Suggestion: go off-line, do design work on such a media parameter. As a new attribute, this might or might not go into sdp-new. SDPng transition ---------------- Presenters: Joerg Ott Colin Perkins Drafts: draft-ietf-mmusic-sdpng-trans-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs created the document to prepare for a smooth transition from SDP to SDPng. They postulated the need for SDP and SDPng to co-exist for a number of years. They propose a protocol-specific approach, wherein one end could offer both protocols to the other end until SDPng support or non-support became clear. Different ways could be used to achieve this: both protocols in the same message, alternative message formats sent to different addresses, initial offer of SDPng with fallback to SDP, etc. They reviewed the approaches that might be taken for different protocols. Tom Taylor promised to contribute to the draft on behalf of MEGACO. Henning Schulzrinne remarked that SIP hasn't tackled basic issues of application of SDPng yet, so it is too early to worry about multipart/alternative. He also suggested the WG make sure that the transition strategy is not too closely tied to the current specific format. SDPng Update ------------ Presenters: Dirk Kutscher Drafts: draft-ietf-mmusic-sdpng-04.txt Slides: 53-mmusic-sdpng.{ppt,pdf,ps} The changes in the latest revision of the draft (-04) include the introduction of a generic syntax mechanism for reusing definitions: sdpng:use, sdpng:group, sdpng:prop. Also, capability negotiation is described now more extensively. The offer/answer model has been incorporated: typically, the answerer matches the offer against list of supported configurations. In formalizing the messages, there may be a problem with some applications (e.g. video) that need a lot of parameters. In such a case, representing each variant as an individual alternative is not practical (far too verbose). Here, a more expressive mechanism is needed (e.g. ranges) as well as algorithms to collapse descriptions. Dirk listed several desiderata for the resolution of these requirements: it must be simple, must no yield too large messages, must be usable with SIP, RTSP, MEGACO, and SAP, support single round-trip negotiation as in offer/answer, and should support multiparty negotiation as well. And the mechanism must be extensible. Dirk presented the conceptual overview of the proposed algorithm contained in the current draft that meets there requirements. Dirk also pointed out a number of open issues to be addressed: * In SDP, descriptions reflect originator viewpoint which often leads to ambiguities, particularly in multiparty scenarios. Should the descriptions reflect a global viewpoint? * SDPng currently has the concept of "external libraries" that may contain collections of definition to be (dynamically) imported. Is this useful? * Numerous requirements have been discussed for capability negotiation. Which (minimal) functionality is really needed? This requires further discussion! * Further on capability negotiation: what are actual semantics of descriptions and negotiation results? - e.g. range of parameters in final descriptions - are senders free to select values? - is signalling required? * SDPng provides mechanisms to label definitions and refer to them by those labels/names; the involved endpoints are likely to use different labels. For capability negotiation, all those references must be resolved; then the collapsing process yields a set of new description instances. How can those (likely rather verbose descriptions), be reduced to a new compact description instance? * Profiles need development, now they are just represented by examples. In particular, a full representation of AVP/RTP needs to be specified, security e.g. MIKEY, possibly QoS, etc. The next steps are to restructure the current spec iinto several documents: a framework document (Informational), the SDPng specification (Standards Track), and Profiles (Standards Track). A complete list of open issues needs to be discussed and resolve on list. Work on profiles needs to progress further. There is a C++ implementation of SDPng-03 using the expat parser. It is being updated to take in newer material. Henning Schulzrinne asked if they had examined schema definition languages and WSDL type definitions. Dirk responded that they had weighed this approached and found that it had complexity issues. He agreed with Henning on the basic concern. Henning identified a second issue: whether SDPng can express capabilities vs. preferences. SDPng and QoS ------------- Presenters: Chairs Drafts: draft-bos-mmusic-sdpng-qos-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} The chairs noted a number of activities relating to QOS signalling including manyfolks work on QoS relating to SIP, media authentication (also from the SIP context), reservation parameters derived from codec, dynamic mapping to RSVP, and diffserv traffic classes. A brief overview of the above draft was given: they identify types of end-to-end QOS information: traffic information, i.e. characterization of the packet traffic for a specific media flow, and sensitivity information that specifies the QOS level given the traffic information (and can be expressed in various ways). The chairs moved on to present a general overview of various QoS architectures showing different ways of how and where QoS may be requested, enforced, and/or provided in the network, including RSVP, diffserv, centralized resource control, among others. They pointed out a number of questions to ask before/when taking up QoS work in the context of the MMUSIC WG (for SDPng): - What have we missed so far? - Do we need QoS information beyond what can be derived from the current SDP? - Where would this information come from? - Is there a need to signal this inband? - Is this signaling session or application layer? - Do we need to synchronize endpoints on (changes in) QoS (profiles)? - How much complexity is acceptable? In summary, we need to determine what the real problem is and whether or not there is a real need to do QoS signaling in the control path The chairs pointed out that QoS, if signalng in the control path, is potentially just yet another dimension of potential and actual configuration. Similar approaches may need to be taken for other areas as well, e.g. security. If QoS is taken up (as part of SDPng), it should just be a specific instantiation of a generalized mechanism. MMUSIC and Electronic Program Guides ------------------------------------ Presenters: Chairs Yuji Nomura Drafts: draft-nomura-mmusic-pguide-requirements-00.txt Slides: 53-mmusic-agenda.{ppt,pdf,ps} 53-mmusic-epg.{ppt,pdf,ps} The chairs introduced the topic of Electronic Program Guides (EPGs): Various groups are looking at broadcasting over IP (DVB-IPI, set-top boxes running IP). Electronic program guides are a necessary part of this. Do we want to work on them? Possible work items are: - SDPng for Electronic Program Guides - SAP and other mechanisms for distributing them - minimal RTSP for retrieval Yuji Nomura presented a first requirements document. He gave a brief definition of program guide and outlined the basic protocol requirements: on demand retrieval, update notification, comprehensive description. He feels that SDPng does not match these requirements well today. He also points out that MPEG-7 offers a comprehensive set of description tools, and could be the basis (or input) for the work. Rob Lanphier asked if any file retrieval protocol would work. Henning Schulzrinne responded: the point is that candidates are available, but they are missing the update notification component. Joerg Ott saw some potential areas of activity fitting into the traditional scope of the Working Group. The was some support for taking up this work in the MMUSIC WG, nobody opposed. The Chairs will examine further for potential uptake. --------------FD7F38C243945B10DAE87DB0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sun Apr 21 10:40:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26023 for ; Sun, 21 Apr 2002 10:40:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01542; Sun, 21 Apr 2002 10:36:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01509 for ; Sun, 21 Apr 2002 10:36:10 -0400 (EDT) Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25980 for ; Sun, 21 Apr 2002 10:36:07 -0400 (EDT) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm1d3cc2defb; Sun, 21 Apr 2002 14:35:49 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm03cc063e2; Fri, 19 Apr 2002 13:54:58 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA26170 for ietf-123-outbound.01@ietf.org; Fri, 19 Apr 2002 08:15:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA25702 for ; Fri, 19 Apr 2002 07:22:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15935; Fri, 19 Apr 2002 07:22:39 -0400 (EDT) Message-Id: <200204191122.HAA15935@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 19 Apr 2002 07:22:39 -0400 Subject: [MMUSIC] I-D ACTION:draft-prandolini-mmusic-jpip-requirements-00.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : JPIP Requirements and Profiles Author(s) : R. Prandolini, R. Clark, S. Houchin Filename : draft-prandolini-mmusic-jpip-requirements-00.txt Pages : 7 Date : 18-Apr-02 This document describes the requirements for an intelligent protocol for serving JPEG 2000 compressed image and metadata (JPIP). This document represents version 2 of the requirements and profiles of the JPIP standard (ISO/IEC 15444-9) found in document WG1N2522 of ISO/IEC JTC1/SC29/WG1 (the JPEG committee). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-prandolini-mmusic-jpip-requirements-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-prandolini-mmusic-jpip-requirements-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-prandolini-mmusic-jpip-requirements-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: <20020418140927.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-prandolini-mmusic-jpip-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-prandolini-mmusic-jpip-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020418140927.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 22 20:08:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18835 for ; Mon, 22 Apr 2002 20:08:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02167; Mon, 22 Apr 2002 20:01:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA02080 for ; Mon, 22 Apr 2002 20:01:04 -0400 (EDT) Received: from wullbinkle.real.com (wullbinkle.real.com [207.188.22.31]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18663 for ; Mon, 22 Apr 2002 20:00:58 -0400 (EDT) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by wullbinkle.real.com (8.12.2/8.12.2) with ESMTP id g3N00SKR020475 for ; Mon, 22 Apr 2002 17:00:28 -0700 Received: from hashpc.real.com ([172.22.123.80]) by real.com (8.12.2/8.12.2) with ESMTP id g3N00RCm009580; Mon, 22 Apr 2002 17:00:27 -0700 Message-Id: <5.1.0.14.2.20020422162122.04e36bf0@mail.real.com> X-Sender: awee@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 22 Apr 2002 16:54:42 -0700 To: mmusic@ietf.org From: Ashley Wee Cc: Ashley Wee , Rob Lanphier In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA02081 Subject: [MMUSIC] RTSP Matrix version 1 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit Here is the first-cut RTSP Matrix based off RFC2326 (April 1998) without section 12 and Appendix A. Any comments on improvements or questions regarding validity is very much welcome. TO DO: - Server, Proxy, Client support are yet to be confirmed. - Section 12 and Appendix A will be included later. - Fix some sentences that have been cropped due to line length limitations. Thanks Ashley Wee RealNetworks 2601 Elliott Ave, Seattle, WA 98121 Phone: (206) 892-6310 email: awee@real.com Keys for Column Headings SRV=Server PRY=Proxy CLT=Client Keys for requirements explicitly callout M=MUST MN=MUST NOT SD=SHOULD SDN=SHOULD NOT SL=SHALL SLN=SHALL NOT MAY=MAY NA=NOT APPLICABLE OPT=OPTIONAL REQ=REQUIRED REC=RECOMMENDED Keys for requirements implicitly callout m=must mn=must not sd=should sdn=should not sl=shall sln=shall not may=may na=not applicable opt=optional req=required rec=recommended Other Keys desc=describe para=parameter mthd=method recd=recording conf=conference info=information pres=presentation attr=attribute app=application init=initialization id=identifier req=required diff=different avail=available sync=synchronize auth=authenticate NOTES: 1. Line numbers are exactly as in RFC. Some blank, page header and footer lines have been deleted. 2. Server,Proxy, Client shows explicit and implicit requirements called out. YET TO BE CONFIRMED. 3. Missing requirement callout does not exclude a requirement. LINE FEATURE SUMMARY SECTION SRV PRY CLT 324control multiple streams 1.3 Terminology 330Multiparty, multimedia pres 1.3 Terminology 343request media data 1.3 Terminology 347Transport layer virtual circuit 1.3 Terminology 351File contain multiple streams 1.3 Terminology may may may 352comprise a pres 1.3 Terminology may may may 353SRV offer agg. control 1.3 Terminology 354container file not embedded in protocol.1.3 Terminology 357timing sink source relationship 1.3 Terminology 358sink must reproduce source timing 1.3 Terminology m m m 366info. transferred as payload 1.3 Terminology 367meta info. in entity-header fields 1.3 Terminology 368content in entity-body 1.3 Terminology 372Datatype/codec specific init.. 1.3 Terminology 374Transport independent info. 1.3 Terminology req req req 379Parameter may be changed before 1.3 Terminology may may may 380or during stream playback. 1.3 Terminology 383playback or recd services 1.3 Terminology 384diff streams from diff SRVs 1.3 Terminology 399Redirection to diff media SRV. 1.3 Terminology 402single media instance 1.3 Terminology 404RTP stream consists of RTP and RTCP 1.3 Terminology 406equivalent to DSM-CC stream([5]). 1.3 Terminology 410structured sequence of octets 1.3 Terminology 411transmit by connection or connectionless1.3 Terminology 415may be machine, record, SRV 1.3 Terminology may may may 419one or more streams media feed 1.3 Terminology 420using pres desc. 1.3 Terminology 422agg. control of those streams 1.3 Terminology 425info. about one or more streams 1.3 Terminology 429SDP "session" for live pres. 1.3 Terminology 434An RTSP response. 1.3 Terminology 435HTTP response indicated explicitly. 1.3 Terminology 438An RTSP request 1.3 Terminology 439HTTP request indicated explicitly. 1.3 Terminology 442complete RTSP "transaction" 1.3 Terminology 457negotiation of transport info. 1.3 Terminology 465New mthds and para. added 1.4 Proto. Prop 468can parsed by standard HTTP or MIME 1.4 Proto. Prop 471re-uses web security mechanisms. 1.4 Proto. Prop 472HTTP auth basic (RFC 2068) 1.4 Proto. Prop 473digest auth (RFC 2069) 1.4 Proto. Prop 474reuse transport/network layer security 1.4 Proto. Prop may may may 478use (UDP) 1.4 Proto. Prop may may may 479reliable datagram protocol RDP, RFC1151 1.4 Proto. Prop 480reliable stream protocol such as TCP 1.4 Proto. Prop 484media stream reside ondiff SRV 1.4 Proto. Prop 485CLT establishes control sessions 1.4 Proto. Prop 487Media synch performed at transport 1.4 Proto. Prop 490control both record and playback 1.4 Proto. Prop 491can alternate between two modes 1.4 Proto. Prop 495Stream control divorced conf. 1.4 Proto. Prop 496initiation protocol create unique id. 1.4 Proto. Prop 498SIP [12] or H.323 1.4 Proto. Prop 511frame-level accuracy SMPTE time stamps 1.4 Proto. Prop 512allow remote digital editing. 1.4 Proto. Prop 515does not impose pres or meta 1.4 Proto. Prop 516can convey type of format to be used 1.4 Proto. Prop 518must contain at least one RTSP URI. 1.4 Proto. Prop 521handled by both app. and 1.4 Proto. Prop sd sd sd 522 transport-layer (SOCKS [14]) firewalls 1.4 Proto. Prop may may may 523SETUP mthd open "hole" for UDP 1.4 Proto. Prop 527reuses HTTP concepts 1.4 Proto. Prop 528 existing infrastructure can be reused. 1.4 Proto. Prop 529(Platform for Internet Content Selection1.4 Proto. Prop 531does not just add mthds to HTTP 1.4 Proto. Prop 535startstream,to stopstream 1.4 Proto. Prop m m m 536SRVs not stream CLTs cannot stop 1.4 Proto. Prop sdn sdn sdn 540CLT can negotiate transport mthd 1.4 Proto. Prop 544If basic are disabled, clean mthd 1.4 Proto. Prop m m m 545CLT determine mthds not implement 1.4 Proto. Prop 547present appropriate user interface. 1.4 Proto. Prop 551 multi-CLT capability. 1.4 Proto. Prop 553easily extensible to multi-CLT 1.4 Proto. Prop 555passing remote would be possible. 1.4 Proto. Prop 556how several CLTs negotiate access; 1.4 Proto. Prop 571will support diff sets of requests. 1.5 Extend RTSP 581implement all header fields described 1.5 Extend RTSPSD SD SD 591Existing mthds can be extended 1.5 Extend RTSP 592para. be ignored by recipient. 1.5 Extend RTSP 595tag to extension be added 1.5 Extend RTSP may may may 597New mthds can be added. 1.5 Extend RTSP 598not understand responds with 501 1.5 Extend RTSP 599sender should not attempt to use mthd 1.5 Extend RTSP sdn sdn sdn 600CLT use OPTIONS mthd to inquire 1.5 Extend RTSP may may may 601SRV SHOULD list mthds 1.5 Extend RTSPSD SD SD 603new version of protocol can be defined 1.5 Extend RTSP 604allow all aspects to change 1.5 Extend RTSP 609may be identified by an RTSP URL. 1.6 Overall Op. may may may 611defined by pres desc. 1.6 Overall Op. 613desc. obtained by CLT 1.6 Overall Op. may may may 625describe one or more press 1.6 Overall Op. 630 may contain several media streams. 1.6 Overall Op. may may may 633make up pres, encodings, 1.6 Overall Op. 634language, para. enable CLT 1.6 Overall Op. 636each stream is individually controllable1.6 Overall Op. 637identified RTSP URL, points media SRV 1.6 Overall Op. 639streams located on diff SRVs 1.6 Overall Op. 640audio and video streams can split 1.6 Overall Op. 642transport mthds SRV capable of 1.6 Overall Op. 644network destination address and 1.6 Overall Op. 645port need to be determined. 1.6 Overall Op. 649transmitted to source of RTSP request, 1.6 Overall Op. 650port number chosen by CLT. 1.6 Overall Op. 651transmitted same reliable stream RTSP. 1.6 Overall Op. 654picks multicast address and port. 1.6 Overall Op. 660multicast address, port and key 1.6 Overall Op. 661given by conf. desc. 1.6 Overall Op. 666sent via separate protocol, 1.7 RTSP States may may may 669delivery continues no RTSP requests 1.7 RTSP States 679issued sequentially on diff TCP 1.7 RTSP States 680SRV maintain "session state" 1.7 RTSP States 681correlate RTSP requests withstream 1.7 RTSP States 684many mthds not contribute to state 1.7 RTSP States 690Causes SRV to allocate resources 1.7 RTSP States 694Starts transmission allocated via SETUP 1.7 RTSP States 697Temporarily halts stream 1.7 RTSP States 700 Frees resources. Session ceases 1.7 RTSP States 703contribute to state use Session header 1.7 RTSP States 705SRV generates session id.s 1.7 RTSP States 710RTSP overlap with HTTP. 1.8 Other Proto may may may 711interact with HTTP initial contact 1.8 Other Proto 713allow diff hand-off points 1.8 Other Proto 715can be retrieved using HTTP or RTSP 1.8 Other Proto 716reduces roundtrips browser scenarios 1.8 Other Proto 717allow RTSP SRVs with no HTTP 1.8 Other Proto 721out-of-band indiff protocol. 1.8 Other Proto 722asymmetric protocol 1.8 Other Proto 723both CLT and SRV issue request 1.8 Other Proto 724 requests are also not stateless 1.8 Other Proto may may may 725set para. and control stream 1.8 Other Proto 737security and proxies. 1.8 Other Proto 738adopt HTTP caches, proxies and auth 1.8 Other Proto 742RTSPnot tied to RTP. 1.8 Other Proto 744existence pres desc. 1.8 Other Proto 745express static and temporal properties 1.8 Other Proto 746containing several media streams. 1.8 Other Proto 778rtsp_URL"rtsp:" | "rtspu:" ) 3.2 RTSP URL 779host [ ":" port ] [ abs_path ] 3.2 RTSP URL 780host= 3.2 RTSP URL 791port=*DIGIT 3.2 RTSP URL 800rtsp protocol (within Internet, TCP) 3.2 RTSP URL 801rtspu an unreliable protocol (UDP). 3.2 RTSP URL 803portempty or not given, port 554assumed 3.2 RTSP URL 809IP addresses URLs SHOULD avoided 3.2 RTSP URL SD SD SD 812…identified bytextual media id. 3.2 RTSP URL 813character set and escape conventions… 3.2 RTSP URL 814URLs refer stream or agg. streams 3.2 RTSP URL may may may 816apply to their whole pres or an individu3.2 RTSP URL 818applied to streams, not pres. 3.2 RTSP URL 846path components RTSP URL opaque CLT 3.2 RTSP URL 847not imply file system structure for SRV.3.2 RTSP URL 855conf. id.s are opaque to RTSP 3.3 Conference 856standard URI encoding mthds 3.3 Conference 857conf. id. MUST be globally 3.3 Conference M M M 860 conf.-id =1*xchar 3.3 Conference 863from multimedia conf.s media SRV 3.3 Conference 866RTSP CLT explicitly providing transport 3.3 Conference 872are opaque strings of arbitrary length 3.4 Session Ids 873linear white space must URL-escaped. 3.4 Session IdsM m M m M m 874session id. MUST be chosen randomly 3.4 Session IdsM M M 875MUST be at least eight octets long 3.4 Session Ids 877ALPH| DIGIT | safe ) 3.4 Session Ids 881relative expresses time relative to star3.5 SMPTE Relat 882expressed as SMPTE time codes 3.5 SMPTE Relat 884hours:minutes:seconds:frames.subframes 3.5 SMPTE Relat 885default smpte format"SMPTE 30 drop" 3.5 SMPTE Relat 886frame rate29.97 frames per second. 3.5 SMPTE RelatMAY MAY MAY 887supported (such as "SMPTE 25") 3.5 SMPTE Relat 888frames field in time value 0 through 29 3.5 SMPTE Relat 889diff. between 30 and 29.97 frames 3.5 SMPTE Relat 890handled dropping first two indices 3.5 SMPTE Relat 891every minute, except every tenth minute.3.5 SMPTE Relat 892If frame valuezero, it may be omitted. 3.5 SMPTE Relat may may may 893are measured in one-hundredth offrame. 3.5 SMPTE Relat 902smpte-range"=" smpte-time "-" [ smpte-ti3.5 SMPTE Relat 903smpte-type="smpte" | "smpte-30-drop" | "3.5 SMPTE Relat 904or timecodes may be added 3.5 SMPTE Relat may may may 905smpte-time=1*2DIGIT ":" 1*2DIGIT ":" 1*23.5 SMPTE Relat 906. 1*2DIGIT ] 3.5 SMPTE Relat 916absolute position 3.6 Normal Play 917relative to beginning of pres 3.6 Normal Play 918decimal fraction 3.6 Normal Play may may may 919inor hours, minutes, and seconds 3.6 Normal Play 920decimal point fractions ofsecond. 3.6 Normal Play 922beginning 0.0 seconds. 3.6 Normal Play 923negative values are not defined. 3.6 Normal Play 924current instant oflive event 3.6 Normal Play may may may 926NPTdefined as in DSM-CC: 3.6 Normal Play 928advances normally play mode (scale = 1),3.6 Normal Play 929advances faster rate in fast scan forwar3.6 Normal Play 930decrements in scan reverse 3.6 Normal Play 931fixed in pause mode 3.6 Normal Play 934npt-range =( npt-time "-" [ npt-time ] )3.6 Normal Play 935npt-time| npt-sec | npt-hhmmss 3.6 Normal Play 936npt-sec=1*DIGIT [ "." *DIGIT ] 3.6 Normal Play 937npt-hhmmss=npt-hh ":" npt-mm ":" npt-ss 3.6 Normal Play 938npt-hh =1*DIGITany positive number 3.6 Normal Play 939npt-mm =1*2DIGIT ; 0-59 3.6 Normal Play 940npt-ss =1*2DIGIT ; 0-59 3.6 Normal Play 947conforms to ISO 8601. 3.6 Normal Play 948npt-sec automatic generation, 3.6 Normal Play 949ntp-hhmmss human readers. 3.6 Normal Play 958now constant live feed 3.6 Normal Play 959absolute time nor zero time 3.6 Normal Play 964Absolute time ISO 8601 timestamps 3.7 Absolute Ti 965Fractions second may be indicated. 3.7 Absolute Ti may may may 967 utc-range ="clock" "=" utc-time "-" [ 3.7 Absolute Ti 968 utc-time =utc-date "T" utc-time "Z" 3.7 Absolute Ti 969 utc-date =8DIGIT ; < YYYYMMDD > 3.7 Absolute Ti 970 utc-time =6DIGIT [ "." fraction ]; < 3.7 Absolute Ti 979unique id.s used to designate new option3.8 Option Tags 980used in Require and Proxy-Require header3.8 Option Tags 983Syntax: 3.8 Option Tags 985 option-tag=1*xchar 3.8 Option Tags 988a reverse domain name 3.8 Option Tags 990register new option with IANA 3.8 Option Tags 998* Name and desc. of option. 3.8.1 Reg. New may may may 999no more than twenty characters long 3.8.1 Reg. New MSD MSD MSD 1000not contain any spaces, control characte3.8.1 Reg. New 1001* Indication of who has change control o3.8.1 Reg. New 1014*reference to a further desc. 3.8.1 Reg. New 1018* For proprietary options, contact info.3.8.1 Reg. New 1023text-based protocol uses ISO 10646 in UT4 RTSP Msg 1024Lines are terminated by CRLF 4 RTSP Msg 1025be prepared to also interpret CR and LF 4 RTSP Msg sd sd sd 1028add optional para. in a seld-describing 4 RTSP Msg opt opt opt 1029number of para. and frequency command lo4 RTSP Msg 1030processing efficiency not a concern 4 RTSP Msg 1032allow easy implementation prototypes in 4 RTSP Msg 1035character set switching invisible US-ASC4 RTSP Msg 1037ISO 8859-1 translates Unicode high order4 RTSP Msg 1039ISO 8859-1 most-significant bit set 11004 RTSP Msg 1042carried over any lower-layer transport 84 RTSP Msg 1045Requests contain mthds, object mthd and 4 RTSP Msg 1046mthds are idempotent unless otherwise no4 RTSP Msg 1047mthds designed to require little or no s4 RTSP Msg 10751. response MUST NOT include msg body 4.4 Msg Length MN MN MN 1076always terminated by first empty line af4.4 Msg Length 1078regardless entity-header fields present 4.4 Msg Length 1079empty line consists of only CRLF 4.4 Msg Length 10812. If Content-Length header field value4.4 Msg Length 1082represents length of msg-body. 4.4 Msg Length 1083 If header fieldnot present,value of zer4.4 Msg Length 10863. By SRV closing connection. 4.4 Msg Length 1087cannot be used to indicate end of reques4.4 Msg Length 1091does not support HTTP/1.1 "chunked" tran4.4 Msg Length 1093requires Content-Length header field. 4.4 Msg Length 1096 SRV should always be able to determine4.4 Msg Length sd sd sd 1098Content-Length must be present if entity4.4 Msg Length m m m 1099rules ensure reasonable behavior if leng4.4 Msg Length 1107general-header = Cache-Control ; Sect5 General Heade 1108 | Connection ; Section 12.10 5 General Heade 1109 | Date ; Section 12.18 5 General Heade 1110 | Via; Section 12.43 5 General Heade 1114request msg from CLT to SRV or vice vers6 Req. 1115within first line ofmsg, mthd to be appl6 Req. 1116resource, id. of resource, and protocol 6 Req. 1117version in use. 6 Req. 1126 Request= Request-Line ; Section 6.1 6 Req. 1127 *(general-header ; Section 5 6 Req. 1128 | request-header ; Section 6.2 6 Req. 1129 | entity-header ) ; Section 8.1 6 Req. 1130 CRLF 6 Req. 1131 [ msg-body ]; Section 4.3 6 Req. 1135 Request-Line = mthd SP Request-URI SP 6.1 Req. Line 1137mthd="DESCRIBE" ; Section 10.2 6.1 Req. Line 1138|"ANNOUNCE" ; Section 10.3 6.1 Req. Line 1139|"GET_PARAMETER"; Section 10.8 6.1 Req. Line 1140|"OPTIONS"; Section 10.1 6.1 Req. Line 1141|"PAUSE" ; Section 10.6 6.1 Req. Line 1142|"PLAY"; Section 10.5 6.1 Req. Line 1143|"RECORD" ; Section 10.11 6.1 Req. Line 1144|"REDIRECT" ; Section 10.10 6.1 Req. Line 1145|"SETUP" ; Section 10.4 6.1 Req. Line 1146|"SET_PARAMETER"; Section 10.9 6.1 Req. Line 1147|"TEARDOWN" ; Section 10.7 6.1 Req. Line 1148|extension-mthd 6.1 Req. Line 1150 extension-mthd = token 6.1 Req. Line 1152 Request-URI = "*" | absolute_URI 6.1 Req. Line 1154 RTSP-Version = "RTSP" "/" 1*DIGIT "." 6.1 Req. Line 1158 request-header = Accept ; Section 12.6.2 Req. Header 1159| Accept-Encoding ; Section 12.2 6.2 Req. Header 1160| Accept-Language ; Section 12.3 6.2 Req. Header 1161| Authorization; Section 12.5 6.2 Req. Header 1162| From; Section 12.20 6.2 Req. Header 1163| If-Modified-Since ; Section 12.23 6.2 Req. Header 1164| Range ; Section 12.29 6.2 Req. Header 1165| Referer; Section 12.30 6.2 Req. Header 1166| User-Agent; Section 12.41 6.2 Req. Header 1168RTSP requests always contain absolute UR6.2 Req. Header 1187asterisk "*" in Request-URI applies to S6.2 Req. Header 1189allowed when mthd does not apply to reso6.2 Req. Header 1192 OPTIONS * RTSP/1.0 6.2 Req. Header 1202responds with an RTSP response msg. 7 Response 1204 Response = Status-Line; Section 7.1 7 Response 1205 *( general-header; Section 5 7 Response 1206 | response-header ; Section 7.1.2 7 Response 1207 | entity-header ) ; Section 8.1 7 Response 1208 CRLF 7 Response 1209 [ msg-body ] ; Section 4.3 7 Response 1214Status-Line protocol version numeric sta7.1 Status-Line 1215textual phrase associated with status co7.1 Status-Line 1216separated by SP characters. 7.1 Status-Line 1217No CR or LF allowed except final CRLF se7.1 Status-Line 1219Status-Line =RTSP-Version SP Status-Code7.1 Status-Line 12233-digit integer result code 7.1.1 Status an 1225Reason-Phrasetextual desc. 7.1.1 Status an 1226Status-Codeautomata 7.1.1 Status an 1228CLT not req. examine or display Reason-P7.1.1 Status an req req req 1238first digit defines class of response 7.1.1 Status an 1239last two digits do not have any categori7.1.1 Status an 1242 * 1xx: info.al - received, continuing 7.1.1 Status an 1243 * 2xx: Success - received, understood,7.1.1 Status an 1245 * 3xx: Redirection - Further action to7.1.1 Status an m m m 1247 * 4xx: CLT Error - bad syntax or canno7.1.1 Status an 1249 * 5xx: SRV Error - failed to fulfill 7.1.1 Status an 1252individual values of numeric status code7.1.1 Status an 1254reason phrases listed here are only reco7.1.1 Status an rec rec rec 1255may replaced by equivalents without affe7.1.1 Status an may may may 1256adopts most HTTP/1.1 [2] status codes 7.1.1 Status an 1257adds RTSP-specific status codes starting7.1.1 Status an 1294Status-Code = "100"; Continue 7.1.1 Status an 1295 | "200"; OK 7.1.1 Status an 1296 | "201"; Created 7.1.1 Status an 1297 | "250"; Low on Storage Space 7.1.1 Status an 1298 | "300"; Multiple Choices 7.1.1 Status an 1299 | "301"; Moved Permanently 7.1.1 Status an 1300 | "302"; Moved Temporarily 7.1.1 Status an 1301 | "303"; See Or 7.1.1 Status an 1302 | "304"; Not Modified 7.1.1 Status an 1303 | "305"; Use Proxy 7.1.1 Status an 1304 | "400"; Bad Request 7.1.1 Status an 1305 | "401"; Unauthorized 7.1.1 Status an 1306 | "402"; Payment req. 7.1.1 Status an 1307 | "403"; Forbidden 7.1.1 Status an 1308 | "404"; Not Found 7.1.1 Status an 1309 | "405"; mthd Not Allowed 7.1.1 Status an 1310 | "406"; Not Acceptable 7.1.1 Status an 1311 | "407"; Proxy auth req. 7.1.1 Status an 1312 | "408"; Request Time-out 7.1.1 Status an 1313 | "410"; Gone 7.1.1 Status an 1314 | "411"; Length req. 7.1.1 Status an 1315 | "412"; Precondition Failed 7.1.1 Status an 1316 | "413"; Request Entity Too Large 7.1.1 Status an 1317 | "414"; Request-URI Too Large 7.1.1 Status an 1318 | "415"; Unsupported Media Type 7.1.1 Status an 1319 | "451"; Parameter Not Understood 7.1.1 Status an 1320 | "452"; conf. Not Found 7.1.1 Status an 1321 | "453"; Not Enough Bandwidth 7.1.1 Status an 1322 | "454"; Session Not Found 7.1.1 Status an 1323 | "455"; mthd Not Valid in State 7.1.1 Status an 1324 | "456"; Header Field Not Valid for Re7.1.1 Status an 1325 | "457"; Invalid Range 7.1.1 Status an 1326 | "458"; ParameterRead-Only 7.1.1 Status an 1327 | "459"; agg. operation not allowed 7.1.1 Status an 1328 | "460"; Only agg. operation allowed 7.1.1 Status an 1329 | "461"; Unsupported transport 7.1.1 Status an 1330 | "462"; Destination unreachable 7.1.1 Status an 1331 | "500"; Internal SRV Error 7.1.1 Status an 1332 | "501"; Not Implemented 7.1.1 Status an 1333 | "502"; Bad Gateway 7.1.1 Status an 1334 | "503"; Service Unavail 7.1.1 Status an 1335 | "504"; Gateway Time-out 7.1.1 Status an 1336 | "505"; RTSP Version not supported 7.1.1 Status an 1337 | "551"; Option not supported 7.1.1 Status an 1338 | extension-code 7.1.1 Status an 1350extension-code = 3DIGIT 7.1.1 Status an 1352Reason-Phrase = *S P,S recommended 10 Mthd Definit rec rec rec 1632ANNOUNCE C->S, S->C P,S optional 10 Mthd Definit opt opt opt 1633GET_PARAMETER C->S, S->C P,S optional 10 Mthd Definit opt opt opt 1634OPTIONS C->S, S->C P,S req. 10 Mthd Definit req req req 1635 (S->C: optional) 10 Mthd Definit opt opt opt 1636PAUSE C->S P,S recommended 10 Mthd Definit rec rec rec 1637PLAY C->S P,S req. 10 Mthd Definit req req req 1638RECORDC->S P,S optional 10 Mthd Definit opt opt opt 1639REDIRECT S->C P,S optional 10 Mthd Definit opt opt opt 1640SETUP C->S S req. 10 Mthd Definit req req req 1641SET_PARAMETER C->S, S->C P,S optional 10 Mthd Definit opt opt opt 1642TEARDOWN C->S P,S req. 10 Mthd Definit req req req 1647PAUSErecommended 10 Mthd Definit rec rec rec 1648builtdoes not support this 10 Mthd Definit 1656request may be issued at any time 10.1 OPTIONS may may may 1657It does not influence SRV state. 10.1 OPTIONS 1688retrieves desc. 10.2 DESCRIBE 1690Accept header to specify desc. formats 10.2 DESCRIBE 1691SRV responds withdesc. 10.2 DESCRIBE 1692reply-response pair constitutes media 10.2 DESCRIBE 1721MUST contain all media init. 10.2 DESCRIBE M M M 1722info. for resource(s)it describes 10.2 DESCRIBE 1723fromsource or than DESCRIBE 10.2 DESCRIBE 1724containscomplete set of media init. 10.2 DESCRIBE 1725CLT SHOULD use those para. 10.2 DESCRIBE SD SD SD 1729of media indirection. 10.2 DESCRIBE 1732 unambiguous means of knowing 10.2 DESCRIBE 1742contain all media init. for set of strea10.2 DESCRIBE 1743discouraging use of DESCRIBE for media i10.2 DESCRIBE 1744avoid looping problems 10.2 DESCRIBE 1747 Media init. isrequirement 10.2 DESCRIBE 1748does not dictatemust be done 10.2 DESCRIBE m m m 1752 * via RTSP's DESCRIBE mthd; 10.2 DESCRIBE 1753 * via some or protocol (HTTP, email at10.2 DESCRIBE 1754 * via command line or standard input 10.2 DESCRIBE 1759recommendedminimal SRVs support 10.2 DESCRIBE rec rec rec 1760recommendedminimal CLTs support 10.2 DESCRIBE rec rec rec 1761acceptsmedia init. file 10.2 DESCRIBE 1762 from standard input, command line, and10.2 DESCRIBE 1769posts desc. 10.3 ANNOUNCE 1770media object identified by request URL 10.3 ANNOUNCE 1771updates session desc. 10.3 ANNOUNCE 1775whole pres desc. should be sent 10.3 ANNOUNCE sd sd sd 1776rarther than just additional components 10.3 ANNOUNCE 1813request forURI specifies transport mecha10.4 SETUP 1815streamis already playing to change 10.4 SETUP 1816If it does not allow this, it MUST respo10.4 SETUP MMAYMMAYMMAY 1817error "455 mthd Not Valid In State" 10.4 SETUP 1818intervening firewalls,CLT must indicate 10.4 SETUP m m m 1822 Since SETUP includes all transport ini10.4 SETUP 1828specifies transport para. acceptable 10.4 SETUP 1829CLT for data transmission 10.4 SETUP 1830transport para. selected by SRV. 10.4 SETUP 1843SRV generates session id.s 10.4 SETUP 1845 SRV MUST bundle setup request 10.4 SETUP M M M 1854return error "459 agg. Operation Not All10.4 SETUP 1859tells SRV to start sending data 10.5 PLAY 1861SETUP requests have been acknowledged 10.5 PLAY 1864positions normal play time to beginning 10.5 PLAY 1865delivers stream data until end 10.5 PLAY 1866requests may be pipelined (queued) 10.5 PLAY may may may 1867MIUST queue PLAY requests to be executed10.5 PLAY M M M 1869delayed until first has been completed. 10.5 PLAY 1871allows precise editing. 10.5 PLAY 1895PLAY request without Range header legal 10.5 PLAY 1896beginning unless stream has been paused 10.5 PLAY 1897paused via PAUSE, stream delivery resume10.5 PLAY 1899can be used by CLT to test SRV liveness.10.5 PLAY 1910containt time parameter 10.5 PLAY may may may 1911specifies time in UTC 10.5 PLAY sd sd sd 1912msgreceived after specified time 10.5 PLAY 1913aid in sync 10.5 PLAY may may may 1914streams obtained from diff sources. 10.5 PLAY 1916SRV replies with actual range 10.5 PLAY 1918alignment of requested range to valid fr10.5 PLAY 1920current position returned in reply 10.5 PLAY 1921unit range in reply same as in request. 10.5 PLAY 1923pres automatically pause 10.5 PLAY 1941live desirable to use clock units: 10.5 PLAY 1952only supporting playback MUST support np10.5 PLAY M M M 1953MAY support clock and smpte formats. 10.5 PLAY MAY MAY MAY 1968stream delivery to be interrupted 10.6 PAUSE 1970playback and recd ofstream halted 10.6 PAUSE 1973group halted 10.6 PAUSE 1974sync of tracks MUST 10.6 PAUSE M M M 1975SRV resources are kept 10.6 PAUSE MAY MAY MAY 1976session and free resources after being p10.6 PAUSE 1977specified with timeout parameter of Sess10.6 PAUSE 1990request may contain Range header 10.6 PAUSE may may may 1992pause point must contain one value 10.6 PAUSE m m m 1993normal play time for stream set to pause10.6 PAUSE 1995pause effective encounting timepoint 10.6 PAUSE 1997If time outside … error "457 Invalid Ran10.6 PAUSE 1999starts at pause point, not played or rec10.6 PAUSE 2000Range header missing, interrupted immedi10.6 PAUSE 2002pause point set to current normal play t10.6 PAUSE 2004request discards all queued PLAY 10.6 PAUSE 2005point in media stream MUST be maintained10.6 PAUSE M M M 2006subsequent PLAY resumes pause point. 10.6 PAUSE 2032If SRV sent data beyond Range header 10.6 PAUSE 2033PLAY would still resume at point in time10.6 PAUSE 2034assumed CLT has discarded data 10.6 PAUSE 2035ensures continuous pause/play cycling 10.6 PAUSE 2039stops stream delivery for given URI, 10.7 TEARDOWN 2040freeing resources associated 10.7 TEARDOWN 2041URI is pres URI session id. invalid 10.7 TEARDOWN 2043all transport defined session desc. 10.7 TEARDOWN 2044SETUP request before played again. 10.7 TEARDOWN 2055retrieves value specified in URI 10.8 GET_PARAME 2057content of reply left to implementation 10.8 GET_PARAME 2058no entity body may test liveness ("ping"10.8 GET_PARAME may may may 2093requests value for a URI 10.9 SET_PARAME 2096contain single parameter to determine re10.9 SET_PARAMESD SD SD 2098several act if all para. successfully 10.9 SET_PARAMEM M M 2100allow to set repeatedly to same value 10.9 SET_PARAMEMAY MAY MAY 2101disallow changing parameter values. 10.9 SET_PARAME 2103transport para. set with SETUP 10.9 SET_PARAMEM M M 2109split in fine-grained for error indicati10.9 SET_PARAME 2111an atomic settings is desirable 10.9 SET_PARAME 2147informs CLT connect another SRV 10.10 REDIRECT m m m 2148mandatory header Location 10.10 REDIRECT 2150Range indicates redirection takes effect10.10 REDIRECT 2152continue send receive TEARDOWN request 10.10 REDIRECT M M M 2153SETUP new session at designated host 10.10 REDIRECT 2166recd range according desc. 10.11 RECORD 2167timestamp reflects start and end time 10.11 RECORD 2168no time range given use start or end tim10.11 RECORD 2170If started, commence recd immediately. 10.11 RECORD 2172recorded data request or another URI 10.11 RECORD 2174not use request URI response 201 10.11 RECORD SD SD SD 2175describes status of request 10.11 RECORD 2176refers new resource and Location 10.11 RECORD 2178media SRV supporting recd of live press 10.11 RECORD M M M 2179recd live must support clock range forma10.11 RECORD 2201interleave RTSP mthds and stream data 10.12 Interleav sd sd sd 2202interleaving should generally avoided 10.12 Interleav 2204SHOULD be used RTSP carried over TCP. 10.12 InterleavSD SD SD 2206encapsulated by an ASCII dollar sign 10.12 Interleav 2207followed byone-byte channel id., 10.12 Interleav 2208followed by length of binary data 10.12 Interleav 2209two-byte integer in network byte order 10.12 Interleav 2210stream data immediately without CRLF 10.12 Interleav 2211Each $ block contains one upper-layer 10.12 Interleav 2214channel id.defined in Transport header 10.12 Interleav 2217When RTP, RTCP msgs are interleaved 10.12 Interleav 2219RTCP sent first avail higher than RTP 10.12 Interleav 2220MAY request RTCP packets another channel10.12 InterleavMAY MAY MAY 2221two channels in interleaved of Transport10.12 Interleav 2224RTCP sync two or more streams 10.12 Interleav 2226tunnel RTP/RTCP through TCP connection 10.12 Interleav 2227transfer onto UDP 10.12 Interleav req req req 2265HTTP status codes are reused. 11 Status Defin 2273warning after RECORD not fulfill 11.1.1 250 Low 2276indicate time period able to record 11.1.1 250 Low may may may 2278CLT should take an estimate. 11.1.1 250 Low sd sd sd 2284used for load balancing 11.2 Redirectio may may may 2285redirecting to SRV topologically closer 11.2 Redirectio 2306mthd specified in request not allowed 11.3.1 405 Mthd 2307rsponse MUST include an Allow header 11.3.1 405 MthdM M M 2308containing list of valid mthds 11.3.1 405 Mthd 2310mthd not indicated during SETUP 11.3.1 405 Mthd 2316recipient of request does not support 11.3.2 451 Para 2321field unknown to media SRV 11.3.3 452 Conf 2326insufficient bandwidth. 11.3.4 453 Not 2332Session header missing, invalid or time 11.3.5 454 Sess 2337cannot process request in its current st11.3.6 455 Mthd 2338response contain an Allow header 11.3.6 455 MthdSD SD SD 2343could not act on req. request header. 11.3.7 456 Head req req req 2360Range value givenout of bounds 11.3.8 457 Inva 2365can be read but not modified 11.3.9 458 Para 2370may not be applied on agg. URL 11.3.10 459 Agg may may may 2371mthd may be applied on a stream URL 11.3.10 459 Agg may may may 2376may not be applied none agg. URL 11.3.11 460 Onl may may may 2377mthd may be applied on pres URL 11.3.11 460 Onl may may may 2382did not contain supported transport 11.3.12 461 Uns 2387data transmission could not be establish11.3.13 462 Des 2388CLT address could not be reached 11.3.13 462 Des 2394Require or Proxy-Require fields was not 11.3.14 551 Opt 2395returned stating option no support 11.3.14 551 Opt sd sd sd 3451Responses are not cacheable 13 Caching 3452exception of DESCRIBE ANNOUNCE 13 Caching 3454DESCRIBE and GET_PARAMETER do not return13 Caching 3457data , to be cached, as well as session 13 Caching 3459SETUP or PLAY request,proxy up-to-date 13 Caching 3461determine up-to-date SETUP or DESCRIBE 13 Caching 3463Last-Modified header with cached copy. 13 Caching 3464 modifies SETUP transport para. 13 Caching 3465forwards request to origin SRV 13 Caching 3466PLAY or PAUSE pass proxy unmodified. 13 Caching 3467proxy delivers media data to CLT 13 Caching 3468making local copy for later reuse 13 Caching 3469given by cache-response directives 13 Caching 3478cache MUST answer any DESCRIBE requests 13 Caching M M M 3485cache simply copies streaming data 13 Caching 3486passes by on its way to CLT 13 Caching 3487does not introduce additional latency. 13 Caching 3489cache appears like regular media 13 Caching 3490 to media origin SRV like CLT 13 Caching 3491store content type, content language 13 Caching 3492store pres desc. 13 Caching 3493cache eliminates all transport-reference13 Caching 3608audio and video track are on two diff SR14.1 Media on D 3609start at slightly diff times and may dri14.1 Media on D may may may 3610CLT can sync two using standard RTP 14.1 Media on D 3611 time scale contained in RTCP sender 14.1 Media on D 3617 multiple continuous media types same en14.2 Streaming 3621components are transported as independen14.2 Streaming 3622desirable to maintaincommon context 14.2 Streaming 3625SRV to keep single storage handle 14.2 Streaming 3626allows treating all streams equally 14.2 Streaming 3627any prioritization of streams by SRV 14.2 Streaming 3630prevent selective retrieval of streams 14.2 Streaming 3633control all streams via single control m14.2 Streaming 3742may treat all files as though container 14.3 Single Str may may may 3744SHOULD use rules set forth in session 14.3 Single StrSD SD SD 4009RTSP syntaxdescribed in an augmented BNF17 Syntax 4010as used in RFC 2068 [2]. 18 Syntax 4014OCTET = 15.1 Base Synta 4015CHAR= 15.1 Base Synta 4021CTL = 15.1 Base Synta 4023CR =15.1 Base Synta 4024LF = 15.1 Base Synta 4026SP = 15.1 Base Synta 4027HT = 15.1 Base Synta 4028<"> = 15.1 Base Synta 4029CRLF=CR LF 15.1 Base Synta 4038LWS =[CRLF] 1*( SP | HT ) 15.1 Base Synta 4039TEXT= 15.1 Base Synta 4040tspecials ="(" | ")" | "<" | ">" | "@" 15.1 Base Synta 4041 | "," | ";" | ":" | "\" | <"> 15.1 Base Synta 4042 | "/" | "[" | "]" | "?" | "=" 15.1 Base Synta 4043 | "{" | "}" | SP | HT 15.1 Base Synta 4045token =1* *(qdtext) <"> ) 15.1 Base Synta 4047qdtext => 15.1 Base Synta 4048quoted-pair ="\" CHAR 15.1 Base Synta 4050msg-header =field-name ":" [ field-valu15.1 Base Synta 4051field-name=token 15.1 Base Synta 4052field-value =*( field-content | LWS ) 15.1 Base Synta 4053field-content= 15.1 Base Synta 4058safe= "\$" | "-" | "_" | "." | "+" 15.1 Base Synta 4059extra = "!" | "*" | "$'$" | "(" | ")" 15.1 Base Synta 4061hex = DIGIT | "A" | "B" | "C" | "D" | "15.1 Base Synta 4062a | "b" | "c" | "d" | "e" | "f" 15.1 Base Synta 4063escape = "\%" hex hex 15.1 Base Synta 4064reserved = ";" | "/" | "?" | ":" | "@"15.1 Base Synta 4066unreserved= alpha | digit | safe | extr15.1 Base Synta 4067xchar = unreserved | reserved | escape15.1 Base Synta 4075Authentication Mechanisms: 16 Security Con 4076 RTSP and HTTP common authentication 16 Security Con 4082Abuse of SRV Log info.: 16 Security Con 4083 RTSP and HTTP SRVs similar logging 16 Security Con 4085protect contents of those logs 16 Security Con 4097Transfer of Sensitive info.: 16 Security Con 4101 protection data privacy and user privac16 Security Con 4105Attacks Based On File and Path Names: 16 Security Con 4108translate portions of request URLs 16 Security Con 4110 SHOULD follow precautions 16 Security ConSD SD SD 4113Personal info.: 16 Security Con 4114privy to same info. 16 Security Con 4118Privacy Issues Connected to Accept Heade16 Security Con 4119same "Accept" headers exist 16 Security Con may may may 4123DNS Spoofing: 16 Security Con 4129hold beyond single use of mapping. 16 Security Con 4131Location Headers and Spoofing: 16 Security Con 4133must check values of Location 16 Security Con m m m 4136 not attempt to invalidate resources 16 Security Con 4139current HTTP specification 16 Security Con 4140future HTTP specifications 16 Security Con may may may 4141provide additional guidance on security 16 Security Con 4152Concentrated denial-of-service attack: 16 Security Con 4160specified destinations for RTSP-initiate16 Security Con 4161 SRV has verified CLT's identity 16 Security Con 4162 database of known users authentication 16 Security Con 4166Session hijacking: 16 Security Con 4171 large, random and non-sequential sessio16 Security Con 4174Authentication: 16 Security Con 4175implement both basic and digest 16 Security ConSD SD SD 4177control stream may be encrypted 16 Security Con may may may 4180Stream issues: 16 Security Con 4181provides for stream control 16 Security Con 4182 are not covered in section, nor in rest16 Security Con 4184RTP, IP multicast, RSVP and IGMP 16 Security Con sd sd sd 4188Persistently suspicious behavior: 16 Security Con 4189SHOULD return error code 403 (Forbidden)16 Security ConSD SD SD 4192aware probe SRV for weaknesses and entry16 Security ConMAY MAY MAY 4193 arbitrarily disconnect and ignore reque16 Security Con 4194violation of local security policy. 16 Security Con 4376control selected, non-contiguous sectionAppendix B: Int 4377rendering those streams with an RTP Appendix B: Int 4378should not affected jumps in NPT Appendix B: Int sdn sdn sdn 4380timestamps MUST be continuous and monotoAppendix B: IntM M M 4390cannot assume CLT can communicate with RAppendix B: Int 4392 timestamp gap as NPT, media agent willAppendix B: Int 4394large enough, RTP timestamp may roll oveAppendix B: Int may may may 4401 RTP-Info field to determine before or Appendix B: Int 4404continuous audio, set RTP marker bit at Appendix B: IntSD SD SD 4406perform playout delay adaptation. Appendix B: Int 4408timestamps should correspond to playbackAppendix B: Int sd sd sd 4415maintain correct display of NPT by RTP tAppendix B: Int 4418first sequence number of next segment. Appendix B: Int 4433describe streams or press in RTSP. Appendix C: Use 4438 SRV are not avail for agg. control. Appendix C: Use 4439retrieved by HTTP or or non-RTSP Appendix C: Use 4440may be received with ANNOUNCE mthds. Appendix C: Use may may may 4442non-agg. control: Appendix C: Use 4444 SRV are avail for agg. control. Appendix C: Use 4445returned in reply toDESCRIBE Appendix C: Use 4446received in an ANNOUNCE mthd. Appendix C: Use 4464a=control: attrused to convey control URC.1.1 Control U 4465used both for session and media desc.s C.1.1 Control U 4466for individual media, it indicates URL C.1.1 Control U 4467controlling particular media stream C.1.1 Control U 4468attr indicates URL for agg. control. C.1.1 Control U 4473may contain relative and absolute URLs C.1.1 Control U may may may 44861. RTSP Content-Base field C.1.1 Control U 44872. RTSP Content-Location field C.1.1 Control U 44883. RTSP request URL C.1.1 Control U 4492* inherits entire base URL. C.1.1 Control U 4496m= fieldused to enumerate streams C.1.2 Media str 4497streams will be rendered with sync C.1.2 Media str 4499port recommendation from SRV to CLT C.1.2 Media str 4500CLT include inSETUP request and may ignoC.1.2 Media str may may may 4501SRV has no preference, it SHOULD set zerC.1.2 Media strSD SD SD 4509payload type(s) are specified in "m=" fiC.1.3 Payload t 4510static payload type no info. req. C.1.3 Payload t 4511dynamic payload type, media attr "rtpmapC.1.3 Payload t req req req 4513encoding name within "rtpmap" attr C.1.3 Payload t may may may 4515X- prefix as specified in SDP C.1.3 Payload t 4517Codec-specific "fmtp" attr C.1.3 Payload t 4518register new encodings follow RFC 1890 C.1.3 Payload t sd sd sd 4520new profile be created and appropriate pC.1.3 Payload t rec rec rec 4521RTP/AVP in "m=" field. C.1.3 Payload t 4525Format-specific para. "fmtp" C.1.4 Format-sp 4528packectization interval "ptime" attr. C.1.4 Format-sp 4544a=range defines total time range C.1.5 Range of 4545length of live sessions deduced from "t"C.1.5 Range of 4547range attr issession-level C.1.5 Range of 4548unitspecified first, followed by value rC.1.5 Range of 4558t= field MUST contain start and stop C.1.6 Time of aM M M 4559times for both agg. and non-agg. C.1.6 Time of a 4560indicate stop time value to be valid C.1.6 Time of aSD SD SD 4562start time equal to or before time DESCRC.1.6 Time of a 4563start and stop times of 0 always avail C.1.6 Time of aMAY MAY MAY 4565non-agg. reflect actual period C.1.6 Time of a sd sd sd 4572SDP, "c=" contains destination address C.1.7 Connectio 4573unicast streams and multicast via SETUP C.1.7 Connectio 4575Unless fixed destination C.1.7 Connectio 4576address, "c=" fieldto set to null value C.1.7 Connectio 4577addresses of type "IP4", value"0.0.0.0".C.1.7 Connectio 4581optional "a=etag" attr identifiesversion C.1.8 Entity opt opt opt 4582SETUP requests may include If-Match C.1.8 Entity may may may 4586opaque and contain any character within C.1.8 Entity may may may 4598could argue"o=" field provides identical C.1.8 Entity 4601o= support multiple session C.1.8 Entity 4607each section MUST have control URL C.2 Agg. ControM M M 4608specified via "a=control:" attr. C.2 Agg. Contro 4625SDP contains complete init. even non-RTSC.2 Agg. Contro rec rec rec 4629no means to request more detail via DESCC.2 Agg. Contro 4633multiple streams can be controlled C.3 Agg. Contro 4635media level "a=control:" attrs C.3 Agg. Contro 4636session-level "a=control:" attr C.3 Agg. Contro 4638If relative,resolved to absolute URLs C.3 Agg. Contro 4642Single stream "a=control:" may be omitteC.3 Agg. Contro may may may 4644If multiple stream MUST contain its own C.3 Agg. ControM M M 4714CLT implementation MUST be able to do foD.1 Client M M M 4716* Generate: SETUP, TEARDOWN, PLAY or RECD.1 Client 4718If RECORD, ANNOUNCE must implemented D.1 Client m m m 4720* Include: CSeq, Connection, Session, TrD.1 Client 4721If ANNOUNCE implemented, capability to D.1 Client 4722Content-Language, Content-Encoding, ContD.1 Client 4723 Length, and Content-Type should be as wD.1 Client sd sd sd 4724* Parse and understand: CSeq, D.1 Client 4725Session, Transport, Content-Language, CoD.1 Client 4726 Encoding, Content-Length, Content-Type.D.1 Client 4727If RECORD, Location is understood D.1 Client m m m 4728implement RTP-Info. D.1 Client sd sd sd 4729* Understand error code received and notD.1 Client 4732does not want one or all status codes. D.1 Client 4733* Expect and respond to asynchronous reqD.1 Client 4734does not need to implement D.1 Client sd sd sd 4735it MUST respond D.1 Client M M M 4742Implement RTP/AVP/UDP asvalid transport.D.1 Client 4743Inclusion of User-Agent header. D.1 Client 4744Understand SDP session desc.s D.1 Client 4745Accept media init. formats D.1 Client 4770generate PAUSE request; D.1.1 Basic Pla 4771implement REDIRECT mthd, Location headerD.1.1 Basic Pla 4778recognize 401 status code; D.1.2 Auth-enab 4779parse and include WWW-auth header; D.1.2 Auth-enab 4780implement Basic auth and Digest auth D.1.2 Auth-enab 4786Implement SETUP, TEARDOWN, OPTIONS and D.2 Server 4787PLAY or RECORD D.2 Server 4788If RECORD implemented, ANNOUNCE D.2 Server 4790Include Connection, Content-Length, ContD.2 Server 4791Content-Encoding, Transport Public D.2 Server 4793Locationif RECORD mthd is. D.2 Server sd sd sd 4794RTP-compliant implement RTP-Info field. D.2 Server sd sd sd 4795Parse and respond D.2 Server 4796Connection, Session, Transport, Require.D.2 Server 4802Implement RTP/AVP/UDP asvalid transport.D.2 Server 4803Inclusion of SRV header. D.2 Server 4804Implement DESCRIBE mthd. D.2 Server 4805Generate SDP session desc.s D.2 Server 4827Recognize Range header D.2.1 Basic Pla 4828return an error if seeking not supportedD.2.1 Basic Pla 4829Implement PAUSE mthd. D.2.1 Basic Pla 4835Include and parse Range header NPT unitsD.2.1 Basic Pla 4836 Implementation SMPTE recommended D.2.1 Basic Pla rec rec rec 4837Include length of media pres D.2.1 Basic Pla 4839Include mappings from timestamps to NPT.D.2.1 Basic Pla 4841 map RTP timestamps to NPT. D.2.1 Basic Pla 4843length info. determine seekable D.2.1 Basic Pla may may may 4845disable seeking length unavail. D.2.1 Basic Pla 4846implement "slider bar" D.2.1 Basic Pla 4847serves as progress indicator and timelinD.2.1 Basic Pla 4850Map RTP timestamps to NPT correct positiD.2.1 Basic Pla 4858Generate 401 status code D.2.2 Auth-enab req req req 4860Parse and include WWW-Authentication D.2.2 Auth-enab 4861Implement Basic and Digest AuthenticatioD.2.2 Auth-enab _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 23 07:16:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12180 for ; Tue, 23 Apr 2002 07:16:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA19032; Tue, 23 Apr 2002 07:15:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA18993 for ; Tue, 23 Apr 2002 07:15:06 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12074; Tue, 23 Apr 2002 07:14:57 -0400 (EDT) Message-Id: <200204231114.HAA12074@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 Apr 2002 07:14:57 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-08.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDP: Session Description Protocol Author(s) : M. Handley, V. Jacobson, C. Perkins Filename : draft-ietf-mmusic-sdp-new-08.txt Pages : 46 Date : 22-Apr-02 This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-new-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-08.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: <20020422135448.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020422135448.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 23 10:28:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19421 for ; Tue, 23 Apr 2002 10:28:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03519; Tue, 23 Apr 2002 10:26:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03454 for ; Tue, 23 Apr 2002 10:26:15 -0400 (EDT) Received: from purple.nge.isi.edu (dial169.east.isi.edu [65.114.169.169]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19179 for ; Tue, 23 Apr 2002 10:26:09 -0400 (EDT) Received: from purple (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.2/8.12.2) with ESMTP id g3NEQCXX001253 for ; Tue, 23 Apr 2002 10:26:12 -0400 (EDT) (envelope-from csp@purple.nge.isi.edu) Message-Id: <200204231426.g3NEQCXX001253@purple.nge.isi.edu> To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-08.txt In-Reply-To: Your message of "Tue, 23 Apr 2002 07:14:57 EDT." <200204231114.HAA12074@ietf.org> Date: Tue, 23 Apr 2002 10:26:12 -0400 From: Colin Perkins Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org There's a new version of the SDP draft available now. The changes in this version are editorial, there shouldn't be any protocol changes. Colin --> Internet-Drafts@ietf.org writes: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : M. Handley, V. Jacobson, C. Perkins > Filename : draft-ietf-mmusic-sdp-new-08.txt > Pages : 46 > Date : 22-Apr-02 > >This memo defines the Session Description Protocol (SDP). SDP >is intended for describing multimedia sessions for the >purposes of session announcement, session invitation, and >other forms of multimedia session initiation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-08.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 23 14:03:03 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29638 for ; Tue, 23 Apr 2002 14:03:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19516; Tue, 23 Apr 2002 14:01:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19475 for ; Tue, 23 Apr 2002 14:01:21 -0400 (EDT) Received: from chiron.nge.isi.edu (chiron.nge.isi.edu [65.114.169.204]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29599 for ; Tue, 23 Apr 2002 14:01:17 -0400 (EDT) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g3NI1KU12539; Tue, 23 Apr 2002 14:01:20 -0400 Message-Id: <200204231801.g3NI1KU12539@chiron.nge.isi.edu> To: mmusic@ietf.org cc: jo@tzi.uni-bremen.de Date: Tue, 23 Apr 2002 14:01:20 -0400 From: Colin Perkins Subject: [MMUSIC] Working group last call: draft-ietf-mmusic-sdp-new-08.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is to announce a working group last call on the revision to SDP (draft-ietf-mmusic-sdp-new-08.txt). In order to meet 3GPP deadlines, we plan to cycle this protocol as a proposed standard RFC (with the aim of advancing to draft standard unchanged after six months, once we have completed interoperability tests). Accordingly, please send any final comments to the mmusic@ietf.org mailing list, or to the working group chairs, by 5th May 2002. Colin >A New Internet-Draft is available from the on-line Internet-Drafts >directories. This draft is a work item of the Multiparty Multimedia >Session Control Working Group of the IETF. > > Title : SDP: Session Description Protocol > Author(s) : M. Handley, V. Jacobson, C. Perkins > Filename : draft-ietf-mmusic-sdp-new-08.txt > Pages : 46 > Date : 22-Apr-02 > >This memo defines the Session Description Protocol (SDP). SDP >is intended for describing multimedia sessions for the >purposes of session announcement, session invitation, and >other forms of multimedia session initiation. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-08.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Apr 24 10:18:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08816 for ; Wed, 24 Apr 2002 10:18:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03173; Wed, 24 Apr 2002 10:17:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03142 for ; Wed, 24 Apr 2002 10:17:35 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08672 for ; Wed, 24 Apr 2002 10:17:30 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3OEGt0E027315; Wed, 24 Apr 2002 16:16:55 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3OEGtV9019677; Wed, 24 Apr 2002 17:16:55 +0300 (EET DST) Message-ID: <3CC6BE50.23312B92@lmf.ericsson.se> Date: Wed, 24 Apr 2002 17:16:48 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Josh Perfetto CC: mmusic@ietf.org Subject: Re: [MMUSIC] Grouping of media lines in SDP draft 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hello, The draft defines a framework to group media lines and then defines two particular semantics for doing so. If you need to use different semantics than the ones already defined in the draft, you can define an extension. In fact, there are already different groups of people working on new semantics to be used with the group framework (being floor control one of them). Regards, Gonzalo Josh Perfetto wrote: > > Hello, > > In the recent draft, , which I believe was > recently submitted to become an RFC, semantics for stream selection (i.e. > where the same stream exists in multiple formats, to be chosen by the > player) seems almost purposely ignored. Was that the case (perhaps because > this is to be addressed by SDPng?). Or is there another standardized way to > do this? > > -Josh > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 25 05:44:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00114 for ; Thu, 25 Apr 2002 05:44:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21369; Thu, 25 Apr 2002 05:43:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21319 for ; Thu, 25 Apr 2002 05:43:30 -0400 (EDT) Received: from mailnpd.hcltech.com ([203.197.145.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00090 for ; Thu, 25 Apr 2002 05:43:25 -0400 (EDT) Received: from npd.hcltech.com (gayramak-pc.hcltech.com [192.168.100.77]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g3P9RM900518; Thu, 25 Apr 2002 14:57:31 +0530 Message-ID: <3CC7CF4A.BEAD5B8C@npd.hcltech.com> Date: Thu, 25 Apr 2002 15:11:30 +0530 From: Gayathri Ramakrishnan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP header table version 1 References: <3CB1B02D.3040409@era.ericsson.se> <3CB28437.D33A9B51@npd.hcltech.com> <3CB294C6.20404@era.ericsson.se> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Magnus, Some comments on the RTSP header table : - Bandwidth request header can be considered as 'Not Applicable' in case of the OPTIONS request. - Retry-After header can be made 'Optional' for 'Get Parameter' and 'Set Parameter', instead of making it as 'Not Applicable' - Location header is'Not Applicable' for all methods other than DESCRIBE and SETUP Some headers that are missing from the table are : If-Match : This header is optional for 'SETUP' and 'Not Applicable' for other methods Host: This header is Optional for all methods Timestamp(R/r) : Optional for all methods According to the revised draft version of RTSP RFC, there is a mention about a header called 'Accept-Ranges'. This can also be included in the table as : Accept-Ranges: Optional for PLAY and 'Not Applicable' for other methods. Thanks, Gayathri Magnus Westerlund wrote: > > Hi Gayathri, > > I also reply to the MMUSIC WG which is the place to discuss/inform about > RTSP stuff. > > Thank you for the proposal, I think we have to wait until the feature > negotiation mechanism is finished and we have defined the couple of > different features that we know this far, until we update the chapter on > implementation requirements. My guess is that by reviewing the minimal > implementation for server and client we can see if that is clear enough > on what is needed for implementation. To that chapter I think we should > add the different features defined and which extra header and > functionality is need compared to the minimum implementation. Doing that > work we will see if something like http summary tables is required or not. > > Cheers > > Magnus > > Gayathri Ramakrishnan wrote: > > >Hi, > >For more clarity of the doc, you also try to add / follow > >some style which has been adopted in the HTTP1.1 requirement > >summary doc. This contains a tabulation which is clearer > >as to what the client/server/proxy has to implement along > >with reference to the appropriate sections. > >Please find the doc attached. > > > >Hope this helps. > >- Gayathri > > > >Magnus Westerlund wrote: > > > >> > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/T/VA > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 25 10:42:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07706 for ; Thu, 25 Apr 2002 10:42:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11615; Thu, 25 Apr 2002 10:39:50 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11583 for ; Thu, 25 Apr 2002 10:39:47 -0400 (EDT) Received: from online.affis.net ([211.237.50.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07629 for ; Thu, 25 Apr 2002 10:39:43 -0400 (EDT) Received: from test (dyn.pool-1-76.r99.r100.scptvl.infoave.net [64.53.71.76]) by online.affis.net (8.11.0/8.11.0) with SMTP id g3PEg7j15308 for ; Thu, 25 Apr 2002 23:42:08 +0900 (KST) Message-Id: <200204251442.g3PEg7j15308@online.affis.net> Reply-To: office_management@desertmail.com From: andrew632111@messpro.com To: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 25 Apr 2002 07:42:07 -0700 Subject: [MMUSIC] ===Medical Breakthrough...Aging can be reversed=== 632111000000000 Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org All HGH (Human Growth Hormone) products are not the same. There are three different types of products. Yet, all three are advertised as if they where the same. The three types are: 1) Homeopathic HGH 2) Pre-cursor HGH 3) Real or synthetic HGH (delivered by injection or, by an oral spray method). Do you know differences? Call us and we'll explain them to you. Our toll free number is 888-621-7300. For more information on HGH read on............ ***************************************************************************** HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)??? Released by your own pituitary gland, HGH starts declining in your 20s, even more in your 30s and 40s, eventually resulting in the shrinkage of major organs -- plus, all other symptoms related to old age. IN THOUSANDS OF CLINICAL STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING: * Reduce Body Fat and Build Lean Muscle WITHOUT EXERCISE! * Enhance Sexual Performance * Remove Wrinkles and Cellulite * Lower Blood Pressure and Improve Cholesterol Profile * Improve Sleep, Vision and Memory * Restore Hair Color and Growth * Strengthen the Immune System * Increase Energy and Cardiac Output * Turn back your body's Biological Time Clock 10 - 20 years * Live Longer AND Stronger All natural and organic plant based FEEL 10 YEARS YOUNGER WITH ORAL SPRAY HGH. GUARANTEED We are the manufacturer and we sell directly to Doctors, Chiropractors, and consumers world wide the highest grade HGH Oral Spray available. With internet marketing, we are able to save advertising cost and pass those savings along to you. But you must act now. To receive more information call us now. TOLL FREE 1-888-621-7300 We must speak to you in person to qualify your usage. All of your questions will be addressed and answered in a friendly, no pressure manner. Our main purpose is to provide you with information so you can make an educated decision. For more information call 1-888-621-7300 If you are on line write down our phone number and call us when you can. Soon, you and your loved ones will be very glad you did. Read what people are saying: "The effects of 6 months of GH on lean body mass and fat were equivalent in magnitude to the changes incurred during 10-20 years of aging." Dr. Daniel Rudman, MD, New England Journal of Medicine. "Within four months, my body fat decreased form 30% down to 21%! I noticed my skin is more supple and my overall mental outlook improved significantly." D.W., New Jersey "We have been on the spray for just 3 weeks now, and besides the tremendous energy we both feel, my husbands allergies and spells of depression have lifted. I am healing extremely fast after an accident and have lost 7 lbs. without trying!" C.B., Flagstaff. AZ Thanks for reading our letter, The HGH Staff USA Division PS: The HGH Staff guarantees the highest quality and lowest price. We manufacture and ship directly to your door. Offer expires 19 April 2002 Call us now 1-888-621-7300 *********************************************************** ======= End of message ======== To Qualify for a Free HGH Consultation call the HGH Staff -- Today. *********************************************************** The following statement is provided to be in compliance with commercial email laws. If you do not wish to receive further mailings, please click reply and type remvoe in the subject box. Then click send. This message is in full compliance with U.S. Federal requirements for commercial email under bill S.1618 Title lll, Section 301, Paragraph (a)(2)(C) passed by the 105th U.S. Congress and is not considered SPAM since it includes a remove mechanism. *********************************************************** This message is not intended for residents in the states of CA, NC, NV, RI, TN, VA & WA. Screening of addresses has been done to the best of our technical ability. *********************************************************** Call us now 1-888-621-7300 for your free HGH consultation. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 25 11:28:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23493 for ; Thu, 25 Apr 2002 11:28:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14143; Thu, 25 Apr 2002 11:27:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA14110 for ; Thu, 25 Apr 2002 11:27:08 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22593 for ; Thu, 25 Apr 2002 11:27:03 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3PFQms7026383; Thu, 25 Apr 2002 17:26:48 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA10478; Thu, 25 Apr 2002 17:26:48 +0200 Message-ID: <3CC82037.90908@era.ericsson.se> Date: Thu, 25 Apr 2002 17:26:47 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gayathri Ramakrishnan CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP header table version 1 References: <3CB1B02D.3040409@era.ericsson.se> <3CB28437.D33A9B51@npd.hcltech.com> <3CB294C6.20404@era.ericsson.se> <3CC7CF4A.BEAD5B8C@npd.hcltech.com> Content-Type: multipart/mixed; boundary="------------070701060607030009050802" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------070701060607030009050802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Thanks, for the review. I hope also some other can review this table. See comments to your comments below. I attach a updated version of the header table. A large shortcoming in this table is the proxy column which is only set for two headers which are the only I have looked at. So if you have knowledge about proxies please think what applies for the different headers. Regards /Magnus Gayathri Ramakrishnan wrote: >Hi Magnus, > >Some comments on the RTSP header table : > >- Bandwidth request header can be considered as 'Not > Applicable' in case of the OPTIONS request. >- Retry-After header can be made 'Optional' for > 'Get Parameter' and 'Set Parameter', instead of making > it as 'Not Applicable' > What is your opinion on the other 'Not Applicable' with question marks for this header. > >- Location header is'Not Applicable' for all methods > other than DESCRIBE and SETUP > > >Some headers that are missing from the table are : > >If-Match : This header is optional for 'SETUP' and 'Not > Applicable' for other methods >Host: This header is Optional for all methods >Timestamp(R/r) : Optional for all methods > Timestamp was not as simple as your comment here made it. It is a optional in request but mandatory to copy from a request to the response. > >According to the revised draft version of RTSP RFC, there >is a mention about a header called 'Accept-Ranges'. This can >also be included in the table as : > >Accept-Ranges: Optional for PLAY and 'Not Applicable' for other >methods. > My interpretation is that this header is only usable in responses. > >Thanks, >Gayathri > >Magnus Westerlund wrote: > >>Hi Gayathri, >> >>I also reply to the MMUSIC WG which is the place to discuss/inform about >>RTSP stuff. >> >>Thank you for the proposal, I think we have to wait until the feature >>negotiation mechanism is finished and we have defined the couple of >>different features that we know this far, until we update the chapter on >>implementation requirements. My guess is that by reviewing the minimal >>implementation for server and client we can see if that is clear enough >>on what is needed for implementation. To that chapter I think we should >>add the different features defined and which extra header and >>functionality is need compared to the minimum implementation. Doing that >>work we will see if something like http summary tables is required or not. >> >>Cheers >> >>Magnus >> >>Gayathri Ramakrishnan wrote: >> >>>Hi, >>>For more clarity of the doc, you also try to add / follow >>>some style which has been adopted in the HTTP1.1 requirement >>>summary doc. This contains a tabulation which is clearer >>>as to what the client/server/proxy has to implement along >>>with reference to the appropriate sections. >>>Please find the doc attached. >>> >>>Hope this helps. >>>- Gayathri >>> -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se --------------070701060607030009050802 Content-Type: text/plain; name="rtspheadertable_v2.txt" Content-Disposition: inline; filename="rtspheadertable_v2.txt" Content-Transfer-Encoding: 7bit RTSP method and header tables version 2 020425 To Do: - Check so no header has been missed - Resolve the ? in when a header is applicable. - Decide on usage of error message bodies. - Write up proxy operations for the headers needing one. ------------------------------------------------------------------------------- Methods method direction object requirement acronym Body DESCRIBE C->S P,S recommended DES r ANNOUNCE C->S, S->C P,S optional ANN R GET_PARAMETER C->S, S->C P,S optional GPR R,r OPTIONS C->S, S->C P,S required OPT (S->C: optional) PAUSE C->S P,S recommended PSE PLAY C->S P,S required PLY RECORD C->S P,S optional REC REDIRECT S->C P,S optional RDR SETUP C->S S required STP SET_PARAMETER C->S, S->C P,S optional SPR R,r? TEARDOWN C->S P,S required TRD Table 2: Overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. Body notes if a method is allowed to carry body and in which direction, R = Request, r=response. Note: There has been some usage of the body to convey more information in error messages for responses containing error codes. Some error messages seem to mandate such usage. Headers The general syntax for header fields is covered in Section 4.2. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [?]. Examples of each header field are given. Information about header fields in relation to methods and proxy processing is summarized in Table 3. The "where" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the "where" column indicates that the header field may be present in all requests and responses. The "proxy" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The rest of the columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. *: The header field is required if the message body is not empty. See sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. "Optional" means that a Client/Server MAY include the header field in a request or response, and a Client/Server MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 12.33). A "mandatory" header field MUST be present in a request, and MUST be understood by the Client/Server receiving the request. A mandatory response header field MUST be present in the response, and the header field MUST be understood by the Client/Server processing the response. "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the Client/Server receiving the request. Similarly, a header field labeled "not applicable" for a response means that the Client/Server MUST NOT place the header field in the response, and the Client/Server MUST ignore the header field in the response. A Client/Server SHOULD ignore extension header parameters that are not understood. The From, Location, and RTP-Info header fields contain a URI. If the URI contains a comma, or semicolon, the URI MUST be enclosed in double quotas ("). Any URI parameters are contained within these quotas. If the URI is not enclosed in double quotas, any semicolon- delimited parameters are header-parameters, not URI parameters. Header Where Proxy DES OPT GPR SPR ANN STP PLY RE* PSE TRD RDR Accept R o - - - - - - - - - - Accept-Encoding R o - - - - - - - - - - Accept-Language R o - - - - - - - - - - Accept-Ranges r - - - - - - o - - - - Allow 405 - - - - m - m m m - - Authorization R o o o o o o o o o o o Bandwidth R o - - o - o o - - - - Blocksize R o - - o - o o - - - - Cache-Control - - - - - o - - - - - Conference R - - - - - o - - - - - Connection o o o o o o o o o o o Content-Base R - - o o o - - - - - - Content-Base r o - o o - - - - - - - Content-Base 4xx o o o o o o o o o o o Content-Encoding R - - o o o - - - - - - Content-Encoding r o - o o - - - - - - - Content-Encoding 4xx o o o o o o o o o o o Content-Language R - - o o o - - - - - - Content-Language r o - o o - - - - - - - Content-Language 4xx o o o o o o o o o o o Content-Length R - - * * * - - - - - - Content-Length r * - * * - - - - - - - Content-Length 4xx * * * * * * * * * * * Content-Location R - - o o o - - - - - - Content-Location r o - o o - - - - - - - Content-Location 4xx o o o o o o o o o o o Content-Type R - - * * * - - - - - - Content-Type r * - * * - - - - - - - Content-Type 4xx * * * * * * * * * * * CSeq Rc m m m m m m m m m m m Date o o o o o o o o o o o Expires r o - - - - - - - - - - From o o o o o o o o o o o Host o o o o o o o o o o o Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR If-Match R - - - - - o - - - - - If-Modified-Since R o - - - - o - - - - - Last-Modified R o - o o - o - - - - - Last-Modified R - - o o o o - - - - - Location R - - - - - - - - - - m Location 3xx m - - - - m - - - - - Proxy-Authenticate 407 m m m m m m m m m m m Proxy-Require R o o o o o o o o o o o Public r - m* - - - - - - - - - Public 501 m* m* m* m* m* m* m* m* m* m* m* Range R - - - - - - o - o - o Range r - - - - - - m* - - - - Referer R o o o o o o o o o o o Require R o o o o o o o o o o o Retry-After 3xx,503 o - o o -? o -? -? -? - - RTP-Info r - - - - - - m - - - - Scale - - - - - - o o - - - Session R - o o o m o m m m m m Session r - c c c m c m m m m m Server R - o o o o - - - - - o Server r o o o o o o o o o o - Speed - - - - - - o - - - - Transport - - - - - m - - - - - Timestamp R o o o o o o o o o o o Timestamp c m m m m m m m m m m m Unsupported r c c c c c c c c c c c User-Agent R m* m* m* m* m* m* m* m* m* m* - User-Agent r - - - - - - - - - - m* Vary r c c c c c c c c c c - Via R amr o o o o o o o o o o o Via c dr m m m m m m m m m m m WWW-Authenticate 401 m m m m m m m m m m m Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR Table 3: Overview of how headers are to be be used for different methods. --------------070701060607030009050802-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Apr 25 14:51:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01805 for ; Thu, 25 Apr 2002 14:51:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01708; Thu, 25 Apr 2002 14:47:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA01668 for ; Thu, 25 Apr 2002 14:47:20 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01743 for ; Thu, 25 Apr 2002 14:47:17 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g3PIkmpY002118; Thu, 25 Apr 2002 11:46:48 -0700 (PDT) Received: from cisco.com (rtp-vpn1-616.cisco.com [10.82.226.104]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA02340; Thu, 25 Apr 2002 11:46:47 -0700 (PDT) Message-ID: <3CC84F17.74EB40D7@cisco.com> Date: Thu, 25 Apr 2002 14:46:47 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo , mmusic@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Codec equality in FID Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit The fid-draft says: " The application encodes the media using the current codec and checks one by one all the "m" lines that are part of the flow. If a particular "m" line contains the codec being used and the direction attribute is "sendonly" or "sendrecv" a copy of the encoded media is sent to the address/port specified in that particular media stream." The question I have here is how we define "codec". To be more specific, let's say I have one media line using RTP and another media line using something different (e.g. SRTP or perhaps a completely different type of transport) but it just so happens that they all list PCMU as a valid encoding method. Now do I need to send PCMU to all the destinations, or just the one with the transport (e.g. RTP) I have chosen to use ? Needless to say properly, I hope the answer is the latter. -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 26 01:33:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16893 for ; Fri, 26 Apr 2002 01:33:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14719; Fri, 26 Apr 2002 01:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA14688 for ; Fri, 26 Apr 2002 01:27:36 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16805 for ; Fri, 26 Apr 2002 01:27:32 -0400 (EDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g3Q5RR0E007214; Fri, 26 Apr 2002 07:27:27 +0200 (MEST) Received: from lmf.ericsson.se (EF5DM00K04BAV71.lmf.ericsson.se [131.160.30.98]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g3Q5RQkw006622; Fri, 26 Apr 2002 08:27:27 +0300 (EET DST) Message-ID: <3CC8E539.11405F48@lmf.ericsson.se> Date: Fri, 26 Apr 2002 08:27:21 +0300 From: Gonzalo Camarillo X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: mmusic@ietf.org References: <3CC84F17.74EB40D7@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Codec equality in FID Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hello, Flemming Andreasen wrote: > > The fid-draft says: > > " The application encodes the media using the current codec and checks > one by one all the "m" lines that are part of the flow. If a > particular "m" line contains the codec being used and the direction > attribute is "sendonly" or "sendrecv" a copy of the encoded media is > sent to the address/port specified in that particular media stream." > > The question I have here is how we define "codec". To be more specific, > let's say I have one media line using RTP and another media line using > something different (e.g. SRTP or perhaps a completely different type of > transport) but it just so happens that they all list PCMU as a valid > encoding method. Now do I need to send PCMU to all the destinations, or > just the one with the transport (e.g. RTP) I have chosen to use ? > Needless to say properly, I hope the answer is the latter. I guess you like the latter solution because it is easier to generate for the user agent, but I would say that the proper thing to do is the former. For instance, we are in the same intranet. You support AMR and G.711. I want you to send me AMR using RTP to my mobile phone directly. However, if you send G.711 at a particular point of time, I want you to send it to a transcoder that will send me AMR. This transcoder is outside our intranet, so I want you to use SRTP to communicate with it. Therefore, the demultiplexing is performed based on the codec in use (i.e., format of the media), and not on the transport in use. Does this make sense to you? Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 26 08:15:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00861 for ; Fri, 26 Apr 2002 08:15:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07349; Fri, 26 Apr 2002 08:14:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07313 for ; Fri, 26 Apr 2002 08:14:22 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00663; Fri, 26 Apr 2002 08:14:18 -0400 (EDT) Message-Id: <200204261214.IAA00663@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 26 Apr 2002 08:14:18 -0400 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Key Management Extensions for SDP and RTSP Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-04.txt Pages : 12 Date : 25-Apr-02 This document defines general extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media. These extensions are presented as a framework, to be used by one or more key management protocols. As such, its use is meaningful only when it is completed by the key management protocol in use. General guidelines are also given on how the framework should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-kmgmt-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020425133930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020425133930.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Apr 26 09:08:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02437 for ; Fri, 26 Apr 2002 09:08:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10206; Fri, 26 Apr 2002 09:06:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA10174 for ; Fri, 26 Apr 2002 09:06:45 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02376 for ; Fri, 26 Apr 2002 09:06:41 -0400 (EDT) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g3QD6DTG009514; Fri, 26 Apr 2002 06:06:13 -0700 (PDT) Received: from cisco.com (rtp-vpn1-616.cisco.com [10.82.226.104]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA05147; Fri, 26 Apr 2002 06:06:12 -0700 (PDT) Message-ID: <3CC950C3.6AC583C2@cisco.com> Date: Fri, 26 Apr 2002 09:06:12 -0400 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: mmusic@ietf.org References: <3CC84F17.74EB40D7@cisco.com> <3CC8E539.11405F48@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Codec equality in FID Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Gonzalo Camarillo wrote: > Hello, > > Flemming Andreasen wrote: > > > > The fid-draft says: > > > > " The application encodes the media using the current codec and checks > > one by one all the "m" lines that are part of the flow. If a > > particular "m" line contains the codec being used and the direction > > attribute is "sendonly" or "sendrecv" a copy of the encoded media is > > sent to the address/port specified in that particular media stream." > > > > The question I have here is how we define "codec". To be more specific, > > let's say I have one media line using RTP and another media line using > > something different (e.g. SRTP or perhaps a completely different type of > > transport) but it just so happens that they all list PCMU as a valid > > encoding method. Now do I need to send PCMU to all the destinations, or > > just the one with the transport (e.g. RTP) I have chosen to use ? > > Needless to say properly, I hope the answer is the latter. > > I guess you like the latter solution because it is easier to generate > for the user agent, but I would say that the proper thing to do is the > former. > > For instance, we are in the same intranet. You support AMR and G.711. I > want you to send me AMR using RTP to my mobile phone directly. However, > if you send G.711 at a particular point of time, I want you to send it > to a transcoder that will send me AMR. This transcoder is outside our > intranet, so I want you to use SRTP to communicate with it. > > Therefore, the demultiplexing is performed based on the codec in use > (i.e., format of the media), and not on the transport in use. > Understood - my question was whether it was on the combination of transport and codec or just codec. If it is done based on both transport and codec, then FID provides a useful way of negotiating both codecs and transport in a single round-trip. If not, then we'll have to do multiple round-trips (e.g. based on SIMCAP information) for this, which I was hoping to avoid. Apart from this, I think we are in danger of getting into fuzzy semantics when we start having more fundamental changes in transports, e.g. ATM - when is a "codec" the same and when is it not ? Can you elaborate more on what the motivation for doing it based on only codec is ? > > Does this make sense to you? > Not sure. We'll call you G, me F, and the transcoder T. If I understand the example correctly, then either a) G sends an SDP with two m lines containing AMR (one RTP and the other SRTP), or b) G sends an SDP with a single m line containing AMR, and somebody in the middle adds another m line for the transcoder. In case a), G may end up receiving both the RTP and SRTP stream if F supports both, which I don't see why you would want to. In case b), there are no duplicate codecs on the m line, and hence the example doesn't apply (F sends AMR to G or F sends PCMU to T). Did I miss something ? -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 29 09:47:54 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07683 for ; Mon, 29 Apr 2002 09:47:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21747; Mon, 29 Apr 2002 09:45:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21706 for ; Mon, 29 Apr 2002 09:45:40 -0400 (EDT) Received: from mailnpd.hcltech.com ([203.197.145.76]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07394 for ; Mon, 29 Apr 2002 09:45:32 -0400 (EDT) Received: from npd.hcltech.com (gayramak-pc.hcltech.com [192.168.100.77]) by mailnpd.hcltech.com (8.11.0/8.11.0) with ESMTP id g3TDU0921570; Mon, 29 Apr 2002 19:00:04 +0530 Message-ID: <3CCD4E30.E8C3C0D@npd.hcltech.com> Date: Mon, 29 Apr 2002 19:14:16 +0530 From: Gayathri Ramakrishnan X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en MIME-Version: 1.0 To: Magnus Westerlund CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP header table version 1 References: <3CB1B02D.3040409@era.ericsson.se> <3CB28437.D33A9B51@npd.hcltech.com> <3CB294C6.20404@era.ericsson.se> <3CC7CF4A.BEAD5B8C@npd.hcltech.com> <3CC82037.90908@era.ericsson.se> Content-Type: multipart/mixed; boundary="------------AB857EE55EC5529063B7DFF7" Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format. --------------AB857EE55EC5529063B7DFF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Magnus, Attached is the file containing what headers apply to a proxy. Here I have considered the case of both a caching proxy as well as a non-caching proxy. As for the case of the 'Retry-After' header: In case of a PAUSE,'Retry-After' header cannot be present in the response ,as the client will not prefer to continue receiving the media data after issuing a PAUSE. In case of a PLAY, 'Retry-After' header should be allowable in the response. The above could hold true in case of multiple PLay Requests. Lets say we assume a scenario with 3 play requests having range as 10 - 20 , 25-30 , 35 - 40. Then incase when the second play request (25 - 30) gets a 'Retry-After' response , the media client implementation should take care of only sending the play request with range as 25 - 30. or Would it be more appropriate to assume that once the connection establishment phase is over (i.e with setup - setting of transport parameters) then we would never have a 'Retry-After' header in the response. I am not sure as to whether we need to look into from this perspective or mark it as "not applicable " for play request. Thanks, - Gayathri Magnus Westerlund wrote: > > Thanks, > > for the review. I hope also some other can review this table. See > comments to your comments below. I attach a updated version of the > header table. A large shortcoming in this table is the proxy column > which is only set for two headers which are the only I have looked at. > So if you have knowledge about proxies please think what applies for the > different headers. > > Regards > > /Magnus > > Gayathri Ramakrishnan wrote: > > >Hi Magnus, > > > >Some comments on the RTSP header table : > > > >- Bandwidth request header can be considered as 'Not > > Applicable' in case of the OPTIONS request. > >- Retry-After header can be made 'Optional' for > > 'Get Parameter' and 'Set Parameter', instead of making > > it as 'Not Applicable' > > > What is your opinion on the other 'Not Applicable' with question marks > for this header. > > > > >- Location header is'Not Applicable' for all methods > > other than DESCRIBE and SETUP > > > > > >Some headers that are missing from the table are : > > > >If-Match : This header is optional for 'SETUP' and 'Not > > Applicable' for other methods > >Host: This header is Optional for all methods > >Timestamp(R/r) : Optional for all methods > > > Timestamp was not as simple as your comment here made it. It is a > optional in request but mandatory to copy from a request to the response. > > > > >According to the revised draft version of RTSP RFC, there > >is a mention about a header called 'Accept-Ranges'. This can > >also be included in the table as : > > > >Accept-Ranges: Optional for PLAY and 'Not Applicable' for other > >methods. > > > My interpretation is that this header is only usable in responses. > > > > >Thanks, > >Gayathri > > > >Magnus Westerlund wrote: > > > >>Hi Gayathri, > >> > >>I also reply to the MMUSIC WG which is the place to discuss/inform about > >>RTSP stuff. > >> > >>Thank you for the proposal, I think we have to wait until the feature > >>negotiation mechanism is finished and we have defined the couple of > >>different features that we know this far, until we update the chapter on > >>implementation requirements. My guess is that by reviewing the minimal > >>implementation for server and client we can see if that is clear enough > >>on what is needed for implementation. To that chapter I think we should > >>add the different features defined and which extra header and > >>functionality is need compared to the minimum implementation. Doing that > >>work we will see if something like http summary tables is required or not. > >> > >>Cheers > >> > >>Magnus > >> > >>Gayathri Ramakrishnan wrote: > >> > >>>Hi, > >>>For more clarity of the doc, you also try to add / follow > >>>some style which has been adopted in the HTTP1.1 requirement > >>>summary doc. This contains a tabulation which is clearer > >>>as to what the client/server/proxy has to implement along > >>>with reference to the appropriate sections. > >>>Please find the doc attached. > >>> > >>>Hope this helps. > >>>- Gayathri > >>> > > -- > > Magnus Westerlund > > Multimedia Technologies, Ericsson Research ERA/T/VA > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se > > ------------------------------------------------------------------------ > RTSP method and header tables > version 2 020425 > > To Do: > > - Check so no header has been missed > > - Resolve the ? in when a header is applicable. > > - Decide on usage of error message bodies. > > - Write up proxy operations for the headers needing one. > > ------------------------------------------------------------------------------- > > Methods > > method direction object requirement acronym Body > DESCRIBE C->S P,S recommended DES r > ANNOUNCE C->S, S->C P,S optional ANN R > GET_PARAMETER C->S, S->C P,S optional GPR R,r > OPTIONS C->S, S->C P,S required OPT > (S->C: optional) > PAUSE C->S P,S recommended PSE > PLAY C->S P,S required PLY > RECORD C->S P,S optional REC > REDIRECT S->C P,S optional RDR > SETUP C->S S required STP > SET_PARAMETER C->S, S->C P,S optional SPR R,r? > TEARDOWN C->S P,S required TRD > > Table 2: Overview of RTSP methods, their direction, and what > objects (P: presentation, S: stream) they operate on. Body notes > if a method is allowed to carry body and in which direction, > R = Request, r=response. > > Note: There has been some usage of the body to convey more information in error messages > for responses containing error codes. Some error messages seem to mandate such usage. > > Headers > > The general syntax for header fields is covered in Section 4.2. This > section lists the full set of header fields along with notes on > syntax, meaning, and usage. Throughout this section, we use [HX.Y] > to refer to Section X.Y of the current HTTP/1.1 specification RFC > 2616 [?]. Examples of each header field are given. > > Information about header fields in relation to methods and proxy > processing is summarized in Table 3. > > The "where" column describes the request and response types in which > the header field can be used. Values in this column are: > > R: header field may only appear in requests; > > r: header field may only appear in responses; > > 2xx, 4xx, etc.: A numerical value or range indicates response > codes with which the header field can be used; > > c: header field is copied from the request to the response. > > An empty entry in the "where" column indicates that the header > field may be present in all requests and responses. > > The "proxy" column describes the operations a proxy may perform on a > header field: > > a: A proxy can add or concatenate the header field if not > present. > > m: A proxy can modify an existing header field value. > > d: A proxy can delete a header field value. > > r: A proxy must be able to read the header field, and thus this > header field cannot be encrypted. > > The rest of the columns relate to the presence of a header field in a > method: > > c: Conditional; requirements on the header field depend on the > context of the message. > > m: The header field is mandatory. > > m*: The header field SHOULD be sent, but clients/servers need to > be prepared to receive messages without that header field. > > o: The header field is optional. > > t: The header field SHOULD be sent, but clients/servers need to > be prepared to receive messages without that header field. > If a stream-based protocol (such as TCP) is used as a > transport, then the header field MUST be sent. > > *: The header field is required if the message body is not > empty. See sections 20.14, 20.15 and 7.4 for details. > > -: The header field is not applicable. > > "Optional" means that a Client/Server MAY include the header field in > a request or response, and a Client/Server MAY ignore the header > field if present in the request or response (The exception to this > rule is the Require header field discussed in 12.33). A "mandatory" > header field MUST be present in a request, and MUST be understood by > the Client/Server receiving the request. A mandatory response header > field MUST be present in the response, and the header field MUST be > understood by the Client/Server processing the response. "Not > applicable" means that the header field MUST NOT be present in a > request. If one is placed in a request by mistake, it MUST be ignored > by the Client/Server receiving the request. Similarly, a header field > labeled "not applicable" for a response means that the Client/Server > MUST NOT place the header field in the response, and the > Client/Server MUST ignore the header field in the response. > > A Client/Server SHOULD ignore extension header parameters that are > not understood. > > The From, Location, and RTP-Info header fields contain a URI. If the > URI contains a comma, or semicolon, the URI MUST be enclosed in > double quotas ("). Any URI parameters are contained within these > quotas. If the URI is not enclosed in double quotas, any semicolon- > delimited parameters are header-parameters, not URI parameters. > > Header Where Proxy DES OPT GPR SPR ANN STP PLY RE* PSE TRD RDR > Accept R o - - - - - - - - - - > Accept-Encoding R o - - - - - - - - - - > Accept-Language R o - - - - - - - - - - > Accept-Ranges r - - - - - - o - - - - > Allow 405 - - - - m - m m m - - > Authorization R o o o o o o o o o o o > Bandwidth R o - - o - o o - - - - > Blocksize R o - - o - o o - - - - > Cache-Control - - - - - o - - - - - > Conference R - - - - - o - - - - - > Connection o o o o o o o o o o o > Content-Base R - - o o o - - - - - - > Content-Base r o - o o - - - - - - - > Content-Base 4xx o o o o o o o o o o o > Content-Encoding R - - o o o - - - - - - > Content-Encoding r o - o o - - - - - - - > Content-Encoding 4xx o o o o o o o o o o o > Content-Language R - - o o o - - - - - - > Content-Language r o - o o - - - - - - - > Content-Language 4xx o o o o o o o o o o o > Content-Length R - - * * * - - - - - - > Content-Length r * - * * - - - - - - - > Content-Length 4xx * * * * * * * * * * * > Content-Location R - - o o o - - - - - - > Content-Location r o - o o - - - - - - - > Content-Location 4xx o o o o o o o o o o o > Content-Type R - - * * * - - - - - - > Content-Type r * - * * - - - - - - - > Content-Type 4xx * * * * * * * * * * * > CSeq Rc m m m m m m m m m m m > Date o o o o o o o o o o o > Expires r o - - - - - - - - - - > >From o o o o o o o o o o o > Host o o o o o o o o o o o > > Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR > > If-Match R - - - - - o - - - - - > If-Modified-Since R o - - - - o - - - - - > Last-Modified R o - o o - o - - - - - > Last-Modified R - - o o o o - - - - - > Location R - - - - - - - - - - m > Location 3xx m - - - - m - - - - - > Proxy-Authenticate 407 m m m m m m m m m m m > Proxy-Require R o o o o o o o o o o o > Public r - m* - - - - - - - - - > Public 501 m* m* m* m* m* m* m* m* m* m* m* > Range R - - - - - - o - o - o > Range r - - - - - - m* - - - - > Referer R o o o o o o o o o o o > Require R o o o o o o o o o o o > Retry-After 3xx,503 o - o o -? o -? -? -? - - > RTP-Info r - - - - - - m - - - - > Scale - - - - - - o o - - - > Session R - o o o m o m m m m m > Session r - c c c m c m m m m m > Server R - o o o o - - - - - o > Server r o o o o o o o o o o - > Speed - - - - - - o - - - - > Transport - - - - - m - - - - - > Timestamp R o o o o o o o o o o o > Timestamp c m m m m m m m m m m m > Unsupported r c c c c c c c c c c c > User-Agent R m* m* m* m* m* m* m* m* m* m* - > User-Agent r - - - - - - - - - - m* > Vary r c c c c c c c c c c - > Via R amr o o o o o o o o o o o > Via c dr m m m m m m m m m m m > WWW-Authenticate 401 m m m m m m m m m m m > > Header Where Proxy DES OPT GPR SPR ANN STP PLY REC PSE TRD RDR > > Table 3: Overview of how headers are to be be used for different > methods. --------------AB857EE55EC5529063B7DFF7 Content-Type: text/plain; charset=us-ascii; name="proxy.txt" Content-Disposition: inline; filename="proxy.txt" Content-Transfer-Encoding: 7bit Caching Non-Caching Proxy Proxy Accept-Encoding r r Accept-Language r r Cache-control r Content-Encoding R r r Content-Encoding r r r Content-Encoding 4xx r r Content-Language R r r Content-Language r r r Content-Language 4xx r r Content-Length R r r Content-Length r r r Content-Length 4xx r r Date m m Expires r r From 4xx a a If-Modified-Since R r Last-Modified r r Proxy-Authenticate a a Proxy-Require r r Public r a a Public 501 a a Server r a a --------------AB857EE55EC5529063B7DFF7-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Apr 29 22:27:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26659 for ; Mon, 29 Apr 2002 22:27:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11510; Mon, 29 Apr 2002 22:26:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA11477 for ; Mon, 29 Apr 2002 22:26:02 -0400 (EDT) Received: from webmail0-2.hinet.net (webmail0-2.hinet.net [168.95.4.235]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26650 for ; Mon, 29 Apr 2002 22:25:57 -0400 (EDT) From: c1227187@ms9.hinet.net Received: from 203.204.45.29 (localhost [127.0.0.1]) by webmail0-2.hinet.net (8.11.1/8.11.1) with SMTP id g3U2RDe01980 for ; Tue, 30 Apr 2002 10:27:13 +0800 (CST) Date: Tue, 30 Apr 2002 10:27:13 +0800 (CST) Message-Id: <200204300227.g3U2RDe01980@webmail0-2.hinet.net> Content-Type: multipart/mixed; boundary="----------=_1020133633-1970-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.316 (Entity 5.212) To: mmusic@ietf.org Subject: [MMUSIC] about rtsp standard Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org This is a multi-part message in MIME format... ------------=_1020133633-1970-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary Hi I have problem,I looked at rfc of rtsp (rfc2326) it talking of use play command, If no range is specified in the request, the current position is returned in the reply. plaease tell me about us for play and redirect,thank you ------------=_1020133633-1970-0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 00:31:02 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29719 for ; Tue, 30 Apr 2002 00:31:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17301; Tue, 30 Apr 2002 00:30:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA17246 for ; Tue, 30 Apr 2002 00:30:07 -0400 (EDT) Received: from ish7.ericsson.com.au (ish7.ericsson.com.au [203.61.155.111]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29689; Tue, 30 Apr 2002 00:30:00 -0400 (EDT) Received: from brsf10.epa.ericsson.se (brsf10 [146.11.8.4]) by ish7.ericsson.com.au (8.11.6+Sun/8.11.6) with ESMTP id g3U4SN019079; Tue, 30 Apr 2002 14:28:23 +1000 (EST) Received: from ericsson.com.au (dhcp-239-110.epa.ericsson.se [146.11.239.110]) by brsf10.epa.ericsson.se (8.11.6+Sun/8.9.3) with ESMTP id g3U4TxN12869; Tue, 30 Apr 2002 14:29:59 +1000 (EST) Message-ID: <3CCDF743.3682E0EA@ericsson.com.au> Date: Tue, 30 Apr 2002 11:45:39 +1000 From: Christian Groves X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tom-PT Taylor CC: "'megaco@ietf.org'" , "'mmusic@ietf.org'" Subject: Re: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt References: <4D79C746863DD51197690002A52CDA0001E8A2A2@zcard0kc.ca.nortel.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 8bit G'Day Tom, I've been having a look at the TDM draft and my main comment is regarding mainly section 4 TDM attributes although it may have some flow on effects. Whilst the list of attributes is rather comprehensive it seems to me that this is a duplication of already defined values. All of the values can be represented by the User Service Information (USI) Q.763 / Bearer Capability information element Q.931. Given that TDM terminations will most likely be used in scenarios where the Call control will be BICC/ISUP/Q.931 the USI will be available in the MGC in the native USI format. It seems pointless to translate the values from native USI format to a SDP format where each sub-value of the USI is defined as seperate attributes. An attribute to carry USI has already been defined in the SG11 work for BICC ie. a=isup_usi: The left most hex digit pair (e.g. EF in the following sequence EF 23 12 13) represents the first binary octet that would be transmitted as per Q.1902.3 § 5.10.) By specifying that a=isup_usi be used instead of the values in section it will mean that currently defined vertical protocol for ISUP and BICC will be consistant with your draft. Regards, Christian Tom-PT Taylor wrote: > > I have recycled this document at last. Material relating to Nx64 kbit/s or > multilink operation has been stripped out, and material relating to H.320 > and H.324 sessions has been modified to conform to the latest views of how > Megaco operates. I forgot to put in the MIME registrations for audio/PCMU, > audio/PCMA, audio/G726xx, and application/octet-stream all over TDM > transport, but I'll do that on the next pass. > > I sent a copy to Jim Renkel, who had urged that requirements for > CAS-signalled TDM be taken into account when I first presented this to > MMUSIC. I have no idea what additional requirements he has in mind, but > I'll see. In the meantime, does anyone else have comments? We need this > for NAS operation. > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, April 09, 2002 8:41 AM > Subject: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Conventions for the use of the Session Description > > Protocol (SDP)for Digital Circuit Connections > Author(s) : T. Taylor > Filename : draft-taylor-mmusic-sdp-tdm-01.txt > Pages : 14 > Date : 08-Apr-02 > > This document describes conventions for using the Session > Description Protocol (SDP) for controlling digital circuits. These > conventions describe > - circuit addressing conventions for use on the SDP 'c=' line > - content of the 'm=' line(s) for digital circuits > - attributes to convey the parameters contained within the Bearer > Capability, Low Layer Compatibility, and High Layer Compatibility > Information Elements of ITU-T Recommendation Q.931. > These conventions have been defined for use in media gateway > control, particularly in support of NAS operation, but may also be > used by IP-based call signalling schemes (SIP, BICC) to control > media exchange over digital circuits. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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. > > ----- > To: > Subject: > Date: Tue, 9 Apr 2002 09:51:14 -0400 > X-Mailer: Internet Mail Service (5.5.2653.19) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > Name: ATT64470 > ATT64470 Type: unspecified type (application/octet-stream) > Encoding: x-uuencode > > Name: draft-taylor-mmusic-sdp-tdm-01.url > draft-taylor-mmusic-sdp-tdm-01.url Type: Internet Shortcut (application/x-unknown-content-type-InternetShortcut) > Encoding: x-uuencode _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 04:50:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10939 for ; Tue, 30 Apr 2002 04:50:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06987; Tue, 30 Apr 2002 04:32:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA06953 for ; Tue, 30 Apr 2002 04:31:59 -0400 (EDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10768 for ; Tue, 30 Apr 2002 04:31:55 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3U8Vp0E005665; Tue, 30 Apr 2002 10:31:51 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA08458; Tue, 30 Apr 2002 10:31:51 +0200 Message-ID: <3CCE5683.7090708@era.ericsson.se> Date: Tue, 30 Apr 2002 10:32:03 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: c1227187@ms9.hinet.net CC: mmusic@ietf.org Subject: Re: [MMUSIC] about rtsp standard References: <200204300227.g3U2RDe01980@webmail0-2.hinet.net> 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-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi c1227187, I think you ask what is the applicability of the following paragraph from section 10.5 "For a on-demand stream, the server replies with the actual range that will be played back. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. If no range is specified in the request, the current position is returned in the reply. The unit of the range in the reply is the same as that in the request." The reasons for having the server respond with a range header is let the client know exactly where the stream starts. This is important for two reasons. The primarily reason is that the client can synchronize the different media. To be able to do that it must match the RTP-Info header information with the corresponding NPT time of the stream. Secondly it allows the client to set any playback clock, slide bar to the correct position. I hope that you know about the work to evolve RTSP to draft standard. A first version of the bis spec is out, but it still lacks rather many bugs. See draft-ietf-mmusic-rfc2326bis-00.txt. The bugs are tracked at "http://rtspspec.sourceforge.net" and information about over telecons are available at "http://rtsp.org" Regards Magnus c1227187@ms9.hinet.net wrote: >Hi > I have problem,I looked at rfc of rtsp (rfc2326) > it talking of use play command, If no range is specified in the request, the current position is returned in the reply. > plaease tell me about us for play and redirect,thank you > -- Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 08:14:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15396 for ; Tue, 30 Apr 2002 08:14:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18546; Tue, 30 Apr 2002 08:13:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18497 for ; Tue, 30 Apr 2002 08:13:22 -0400 (EDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15362; Tue, 30 Apr 2002 08:13:15 -0400 (EDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3UCCjd07313; Tue, 30 Apr 2002 08:12:45 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 08:12:49 -0400 Message-ID: <4D79C746863DD51197690002A52CDA0001E8A3B2@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Christian Groves'" Cc: "'megaco@ietf.org'" , "'mmusic@ietf.org'" Subject: RE: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt Date: Tue, 30 Apr 2002 08:12:48 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org The whole point of the draft is to relieve MGs of the necessity to understand legacy telephony signalling protocols. I will allow the WGs to comment on whether this is the right approach, since your proposal is obviously a workable alternative. -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com.au] Sent: Monday, April 29, 2002 9:46 PM To: Taylor, Tom-PT [CAR:B800:EXCH] Cc: 'megaco@ietf.org'; 'mmusic@ietf.org' Subject: Re: [MMUSIC] FW: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt G'Day Tom, I've been having a look at the TDM draft and my main comment is regarding mainly section 4 TDM attributes although it may have some flow on effects. Whilst the list of attributes is rather comprehensive it seems to me that this is a duplication of already defined values. All of the values can be represented by the User Service Information (USI) Q.763 / Bearer Capability information element Q.931. Given that TDM terminations will most likely be used in scenarios where the Call control will be BICC/ISUP/Q.931 the USI will be available in the MGC in the native USI format. It seems pointless to translate the values from native USI format to a SDP format where each sub-value of the USI is defined as seperate attributes. An attribute to carry USI has already been defined in the SG11 work for BICC ie. a=isup_usi: The left most hex digit pair (e.g. EF in the following sequence EF 23 12 13) represents the first binary octet that would be transmitted as per Q.1902.3 § 5.10.) By specifying that a=isup_usi be used instead of the values in section it will mean that currently defined vertical protocol for ISUP and BICC will be consistant with your draft. Regards, Christian Tom-PT Taylor wrote: > > I have recycled this document at last. Material relating to Nx64 kbit/s or > multilink operation has been stripped out, and material relating to H.320 > and H.324 sessions has been modified to conform to the latest views of how > Megaco operates. I forgot to put in the MIME registrations for audio/PCMU, > audio/PCMA, audio/G726xx, and application/octet-stream all over TDM > transport, but I'll do that on the next pass. > > I sent a copy to Jim Renkel, who had urged that requirements for > CAS-signalled TDM be taken into account when I first presented this to > MMUSIC. I have no idea what additional requirements he has in mind, but > I'll see. In the meantime, does anyone else have comments? We need this > for NAS operation. > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Tuesday, April 09, 2002 8:41 AM > Subject: I-D ACTION:draft-taylor-mmusic-sdp-tdm-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Conventions for the use of the Session Description > > Protocol (SDP)for Digital Circuit Connections > Author(s) : T. Taylor > Filename : draft-taylor-mmusic-sdp-tdm-01.txt > Pages : 14 > Date : 08-Apr-02 > > This document describes conventions for using the Session > Description Protocol (SDP) for controlling digital circuits. These > conventions describe > - circuit addressing conventions for use on the SDP 'c=' line > - content of the 'm=' line(s) for digital circuits > - attributes to convey the parameters contained within the Bearer > Capability, Low Layer Compatibility, and High Layer Compatibility > Information Elements of ITU-T Recommendation Q.931. > These conventions have been defined for use in media gateway > control, particularly in support of NAS operation, but may also be > used by IP-based call signalling schemes (SIP, BICC) to control > media exchange over digital circuits. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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-taylor-mmusic-sdp-tdm-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. > > ----- > To: > Subject: > Date: Tue, 9 Apr 2002 09:51:14 -0400 > X-Mailer: Internet Mail Service (5.5.2653.19) > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > Name: ATT64470 > ATT64470 Type: unspecified type (application/octet-stream) > Encoding: x-uuencode > > Name: draft-taylor-mmusic-sdp-tdm-01.url > draft-taylor-mmusic-sdp-tdm-01.url Type: Internet Shortcut (application/x-unknown-content-type-InternetShortcut) > Encoding: x-uuencode _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 08:36:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17226 for ; Tue, 30 Apr 2002 08:36:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20456; Tue, 30 Apr 2002 08:35:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20424 for ; Tue, 30 Apr 2002 08:35:40 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16816 for ; Tue, 30 Apr 2002 08:35:35 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UCZYs7007767 for ; Tue, 30 Apr 2002 14:35:34 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 30 14:33:19 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Apr 2002 14:22:38 +0200 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE41D7@esealnt416> From: "Fredrik Lindholm (ERA)" To: mmusic@ietf.org Date: Tue, 30 Apr 2002 14:32:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] draft-ietf-mmusic-kmgmt-ext-04.txt Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org We recently submitted a new version of the draft-ietf-mmusic-kmgmt-ext. In this version many of the comments raised in Minneapolis and at the mailing list are addressed. The open issue is still, how to include the key management data. The main problem is whether to extract the key management protocol's (KMP) parameters from the KMP data and insert these in SDP/RTSP as separate attribute fields or whether to treat the KMP data as one single value. The two approaches can be visualized as: a=key-mgmt:MyKeyMgmt algorithm=aes key=... mac=... and a=key-mgmt:MyKeyMgmt HsdjhsUYUdsjqiHSD... (Similar header is then also defined for RTSP) The first approach might be appealing as almost each attribute is "human readable" and can be parsed by SDP. However, we believe that there are too many disadvantages with the first approach compared to the second. We have tried to summarize the main problems (as we currently see it) with using the first approach. These are: * When a new attribute/parameter is added to the KMP, this must be registered not only in the KMP, but also in SDP and RTSP. I.e., changes propagate through several protocols. * When adding another KMP, one need to map the payloads normally used by the KMP to both SDP and RTSP values. * It can increase the bandwidth consumption (how much will of course depend on how the KMP encoded the data normally). We believe these problems are serious enough to motivate the use of the second approach, i.e., include the KMP data as one single value. Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 10:32:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22469 for ; Tue, 30 Apr 2002 10:32:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28019; Tue, 30 Apr 2002 10:28:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA27987 for ; Tue, 30 Apr 2002 10:28:23 -0400 (EDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22261 for ; Tue, 30 Apr 2002 10:28:17 -0400 (EDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g3UERcs7007155; Tue, 30 Apr 2002 16:27:38 +0200 (MEST) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA17780; Tue, 30 Apr 2002 16:27:38 +0200 Message-ID: <3CCEA9F6.2050506@era.ericsson.se> Date: Tue, 30 Apr 2002 16:28:06 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Gayathri Ramakrishnan CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP header table version 1 References: <3CB1B02D.3040409@era.ericsson.se> <3CB28437.D33A9B51@npd.hcltech.com> <3CB294C6.20404@era.ericsson.se> <3CC7CF4A.BEAD5B8C@npd.hcltech.com> <3CC82037.90908@era.ericsson.se> <3CCD4E30.E8C3C0D@npd.hcltech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi, I will start with commenting on your proxy table. - Data header: I believe it should be both a and m attribute for proxies. - From header: I don't see any harm in allowing a proxy to add to the from field but what is the reason for it? Shouldn't the from filed contain the email of the responsible request issuing user? Shouldn't this header also have an "r"? Also don't understand the 4xx designation on this header. If the from header shall be usable it must be added onto request. - if-match header: This seem to also be a header requiring "r" note. - proxy-authenticate: In my opinion this should have an "amr" usage. I base this on what the HTTP spec says about the header. - Proxy-require: Should this header also be possible to add/concatenate by proxies? - public seems to to require that a proxy can both add, delete and modify the header and of course read it, making it "admr". - Server: I don't agree that a proxy may add this header. RFC 2616 has a MUST NOT modify this header. Gayathri Ramakrishnan wrote: >As for the case of the 'Retry-After' header: > >In case of a PAUSE,'Retry-After' header cannot be present >in the response ,as the client will not prefer to continue >receiving the media data after issuing a PAUSE. > Yes, I agree, > > >In case of a PLAY, 'Retry-After' header should be allowable >in the response. >The above could hold true in case of multiple PLay Requests. > >Lets say we assume a scenario with 3 play requests having >range as 10 - 20 , 25-30 , 35 - 40. >Then incase when the second play request (25 - 30) gets >a 'Retry-After' response , the media client implementation should >take care of only sending the play request with range as >25 - 30. > >or > >Would it be more appropriate to assume that once the connection >establishment phase is over (i.e with setup - setting of >transport parameters) then we would never have >a 'Retry-After' header in the response. > > >I am not sure as to whether we need to look into from >this perspective or mark it as "not applicable " for >play request. > I think we can assume that the client will not receive a 3xx response after setup. If the server want's to do redirect at that time it should use the REDIRECT method. The question is on which methods you could get service unavailable. For me it seems reasonable that you should not get that answer after the client has established a session. So I think we can remove the Retry-after from all methods except the stateless and setup. Cheers Magnus Westerlund Multimedia Technologies, Ericsson Research ERA/T/VA ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Apr 30 21:29:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14268 for ; Tue, 30 Apr 2002 21:29:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09188; Tue, 30 Apr 2002 21:28:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09157 for ; Tue, 30 Apr 2002 21:28:14 -0400 (EDT) Received: from freightmart.com (116-154-239-64.pajo.com [64.239.154.116] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14264 for ; Tue, 30 Apr 2002 21:28:10 -0400 (EDT) From: lisa@freightmart.com Message-Id: <200205010128.VAA14264@ietf.org> Content-Type: text/html; charset=US-ASCII Date: Tue, 30 Apr 2002 18:32:34 -0700 To: mmusic@ietf.org X-Mailer: Version 5.0 Subject: [MMUSIC] An Invitation from Lisa@freightmart.com Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org FREIGHTMART Mail Campaign


To be REMOVED from any future offers, simply CLICK HERE!
For more info, CLICK HERE!
_______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic