From mmusic-admin@ietf.org Fri Feb 1 03:43:34 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 DAA03860 for ; Fri, 1 Feb 2002 03:43:34 -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 DAA02010; Fri, 1 Feb 2002 03:42: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 DAA01979 for ; Fri, 1 Feb 2002 03:41:59 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03818 for ; Fri, 1 Feb 2002 03:41:56 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g118fsC11582; Fri, 1 Feb 2002 09:41:54 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA23680; Fri, 1 Feb 2002 09:41:54 +0100 Message-ID: <3C5A54D2.315BDE11@era.ericsson.se> Date: Fri, 01 Feb 2002 09:41:54 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [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: Unclearities regarding pause with range (477423) 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 Hi, Rob I still dont agree with the resolution. I have objections against the following part of a sentence: "but if multiple range specifiers are present, npt/smpte takes precence over time." My interpretation for PLAY is that you always first look at the time=value. You don't actually perform the request until your wall clock is equal or after the time specifed in time=. Then when performing the PLAY you will look and perform as the npt/smpte/utc specifies. So I would like to remove the part about npt/smpte taking presendence as it changes the behaviour compared to PLAY. My opinion is that they should use the same mechanism as it simplifies implementation and also align behviour. What is your opinion? Rob Lanphier wrote: > * RESOLVED: Only a single range specifier (format "value-" where "value" > is a time) is allowed for pause. time="execution time in UTC" may also be > used, but if multiple range specifiers are present, npt/smpte takes > precence over time. A new example will be provided. > > Rob > ---- 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mailman-owner@ietf.org Fri Feb 1 06:06: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 GAA15829 for ; Fri, 1 Feb 2002 06:06:09 -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 GAA12349 for ; Fri, 1 Feb 2002 06:06:12 -0500 (EST) Date: Fri, 1 Feb 2002 06:06:12 -0500 (EST) Message-Id: <200202011106.GAA12349@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 Fri Feb 1 07:03:06 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 HAA19464 for ; Fri, 1 Feb 2002 07:03: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 HAA09579; Fri, 1 Feb 2002 07:01:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA09548 for ; Fri, 1 Feb 2002 07:01:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19419; Fri, 1 Feb 2002 07:01:42 -0500 (EST) Message-Id: <200202011201.HAA19419@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, 01 Feb 2002 07:01:42 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-offer-answer-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : An Offer/Answer Model with SDP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-mmusic-sdp-offer-answer-00.txt Pages : 24 Date : 31-Jan-02 This document defines a mechanism by which two entities can make use of SDP to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-offer-answer-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-offer-answer-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: <20020131132950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-offer-answer-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-offer-answer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020131132950.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 Feb 1 12:08:41 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 MAA04008 for ; Fri, 1 Feb 2002 12:08:41 -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 MAA27797; Fri, 1 Feb 2002 12:08:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27758 for ; Fri, 1 Feb 2002 12:08:16 -0500 (EST) Received: from bullwinkle.real.com (bullwinkle.real.com [207.188.22.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03970 for ; Fri, 1 Feb 2002 12:08:12 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Fri, 01 Feb 2002 09:07:39 -0800 Received: from mmmm (12-231-29-208.client.attbi.com [12.231.29.208]) by prognet.com (8.9.2/8.9.0) with ESMTP id JAA12896; Fri, 1 Feb 2002 09:07:46 -0800 (PST) Date: Fri, 1 Feb 2002 09:04:25 -0800 (PST) From: Rob Lanphier To: Magnus Westerlund cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: Unclearities regarding pause with range (477423) In-Reply-To: <3C5A54D2.315BDE11@era.ericsson.se> 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 I don't have a strong opinion on this myself, but this is probably one I should ask around about here at RN. To be honest, in my haste to get the email out last night, I overlooked that part of the discussion on the list. I'll get back to you next week on this one. Rob On Fri, 1 Feb 2002, Magnus Westerlund wrote: > Hi, Rob > > I still dont agree with the resolution. I have objections against the following > part of a sentence: > > "but if multiple range specifiers are present, npt/smpte takes precence over > time." > > My interpretation for PLAY is that you always first look at the time=value. You > don't actually perform the request until your wall clock is equal or after the > time specifed in time=. Then when performing the PLAY you will look and perform > as the npt/smpte/utc specifies. So I would like to remove the part about > npt/smpte taking presendence as it changes the behaviour compared to PLAY. My > opinion is that they should use the same mechanism as it simplifies > implementation and also align behviour. > > What is your opinion? > > > Rob Lanphier wrote: > > > * RESOLVED: Only a single range specifier (format "value-" where "value" > > is a time) is allowed for pause. time="execution time in UTC" may also be > > used, but if multiple range specifiers are present, npt/smpte takes > > precence over time. A new example will be provided. > > > > Rob > > ---- > > 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 > > > > _______________________________________________ > 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 Feb 1 18:39: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 SAA14191 for ; Fri, 1 Feb 2002 18:39: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 SAA17307; Fri, 1 Feb 2002 18:38: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 SAA17274 for ; Fri, 1 Feb 2002 18:37:58 -0500 (EST) Received: from bullwinkle.real.com (bullwinkle.real.com [207.188.22.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14168 for ; Fri, 1 Feb 2002 18:37:55 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Fri, 01 Feb 2002 15:37:29 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id PAA06987 for ; Fri, 1 Feb 2002 15:37:20 -0800 (PST) Date: Fri, 1 Feb 2002 15:39:17 -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 Telecon Agenda - 06 Feb 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 is the agenda for the RTSP telecon that will happen on Wednesday, February 6 at 9 am PST (17:00 GMT). Please RSVP no later than end-of-business Monday (PST). Agenda also available online: http://rtsp.org/2002/telecon/agenda06Feb.html Thanks Rob ---- Rtsp Tc Agenda06 Feb2002 ------------------------------------------------------------------------ 1. Last Telecon 1. Review Action Items/New Issues 2. Discussed and Resolved 3. Discussed and still pending 2. This Telecon Last Telecon Minutes: http://rtsp.org/2002/telecon/minutes23Jan.html Review Action Items/New Issues * ACTION ITEM (RL): submit proposal to eliminate queued play * ACTION ITEM (MW): continuous sequence number filing * ACTION ITEM (JS): Write up aggregate URL proposal. Discussed and Resolved * http://rtsp.org/bug477421 - When to send response o RESOLVED: server allowed to send immediate response with no sequence number. server should NOT set sequence number * http://rtsp.org/bug477425 - Inconsistency between timeformats o RESOLVED: Extend this to other time formats, and probably clarify the semantics of this particular syntax. Should start at pause point or the beginning. * http://rtsp.org/bug477427 - Transport model requirements o RESOLVED: define header and response for non-persistent connections. Default is connection-oriented, and connectionless MAY be implemented. Look into "supported" header. Discussed and still pending * http://rtsp.org/bug477423 - Unclearities regarding pause with range o RESOLVED: Only a single range specifier (format "value-" where "value" is a time) is allowed for pause. time="execution time in UTC" may also be used. A new example will be provided. o PENDING: If multiple range specifiers are present, we need to determine which takes precedence (npt/smpte or time?). * http://rtsp.org/bug477424 - How to queue timed plays? o PENDING: propose elimination of queued play to list. Separate email necessary. Postpone 477424 until queue play is resolved * http://rtsp.org/bug477428 - Priorites between aggregated & non cntrl o PENDING: await resolution of queued play. Aggregate control issue needs larger discussion This Telecon A little bit different format this time around. We've got two big, interrelated topics, for which there are a series of subissues. I'd like to come to some sort of consensus on the two issues * Mixing Aggregate and Non-aggregate Control - see the email thread. This is related to several bugs: o http://rtsp.org/bug477400 - Play without range while playing o http://rtsp.org/bug477428 - Priorites between aggregated & non cntrl o http://rtsp.org/bug483356 - media URL in Play on aggregated session o http://rtsp.org/bug493270 - PAUSE/Play on single media in aggregate o http://rtsp.org/bug506412 - RTSP Teardown functionallity * Eliminate queued play - see the email thread and http://rtsp.org/bug508211 . This relates to several issues o http://rtsp.org/bug477424 - How to queue timed plays? o http://rtsp.org/bug477432 - RTP info and queued plays o http://rtsp.org/bug493265 - Pause - Play behaviour clarification o http://rtsp.org/bug507882 - RTP timestamps when playing after pause _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Feb 2 12:01: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 MAA05479 for ; Sat, 2 Feb 2002 12:01:00 -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 MAA04689; Sat, 2 Feb 2002 12:00: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 MAA04569 for ; Sat, 2 Feb 2002 12:00:13 -0500 (EST) 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 MAA05467 for ; Sat, 2 Feb 2002 12:00:08 -0500 (EST) 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 g12H02408684; Sat, 2 Feb 2002 18:00:02 +0100 (MET) Message-ID: <3C5C1B02.73F44DC9@tzi.uni-bremen.de> Date: Sat, 02 Feb 2002 17:59:46 +0100 From: Joerg Ott X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org CC: mankin@isi.edu, csp@isi.edu, jdrosen@dynamicsoft.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] WG Last Call for Offer/Answer 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 Folks, this is to announce Working Group Last Call on draft-ietf-mmusic-sdp-offer-answer-00.txt for Proposed Standard. Please note that this document is a revision of draft-rosenberg-mmusic-offer-answer-00.txt. The WG Last Call is to expire in two weeks, on 16 Feb 2002. Please note that this document is referenced by SIP bis06 and thus is crucial to the 3G work. So, please, review this document quickly (it is not that long) and should you have any comments, please submit them asap to the MMUSIC mailing list and the authors. Thanks a lot, Joerg co-chair, MMUSIC _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sun Feb 3 20:53: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 UAA02114 for ; Sun, 3 Feb 2002 20:53:59 -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 UAA19400; Sun, 3 Feb 2002 20:53: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 UAA19367 for ; Sun, 3 Feb 2002 20:53:35 -0500 (EST) Received: from smtp.huawei.com ([61.144.161.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02110 for ; Sun, 3 Feb 2002 20:53:29 -0500 (EST) Received: from x18916 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GQZJR000.D3P; Mon, 4 Feb 2002 09:49:48 +0800 Message-ID: <003c01c1ad1e$91b273a0$db100b0a@huawei.com.cn> From: "Peili Xu" To: Cc: References: <3C5C1B02.73F44DC9@tzi.uni-bremen.de> Date: Mon, 4 Feb 2002 09:52:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id UAA19368 Subject: [MMUSIC] Question About SDO Offer/Answer 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: 8bit In section 4 "Protocol Operatioin": It says that the agent Must Not generate a new offer if it has received an offer which it has not yet answered or rejected. But for early media we use 180/PRACK to offer and answer the early media just before the Invite/200 interaction is completed. Is this method break the Offer/Answer law? ----- Original Message ----- From: Joerg Ott To: Cc: ; ; Sent: Sunday, February 03, 2002 12:59 AM Subject: WG Last Call for Offer/Answer > Folks, > > this is to announce Working Group Last Call on > > draft-ietf-mmusic-sdp-offer-answer-00.txt > > for Proposed Standard. Please note that this document is a > revision of draft-rosenberg-mmusic-offer-answer-00.txt. > > The WG Last Call is to expire in two weeks, on 16 Feb 2002. > > Please note that this document is referenced by SIP bis06 > and thus is crucial to the 3G work. So, please, review this > document quickly (it is not that long) and should you > have any comments, please submit them asap to the MMUSIC > mailing list and the authors. > > Thanks a lot, > Joerg > co-chair, MMUSIC > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sun Feb 3 21:35:31 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 VAA03392 for ; Sun, 3 Feb 2002 21:35:31 -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 VAA21142; Sun, 3 Feb 2002 21:35: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 VAA21107 for ; Sun, 3 Feb 2002 21:35:17 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03345 for ; Sun, 3 Feb 2002 21:35:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.49]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g142ZH6Y011995; Sun, 3 Feb 2002 21:35:20 -0500 (EST) Message-ID: <3C5DF33A.783BB466@dynamicsoft.com> Date: Sun, 03 Feb 2002 21:34:34 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peili Xu CC: mmusic@ietf.org References: <003c01c1ad1e$91b273a0$db100b0a@huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Question About SDO Offer/Answer 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 Peili Xu wrote: > > In section 4 "Protocol Operatioin": > > It says that the agent Must Not generate a new offer if it has received > an offer which it has not yet answered or rejected. > > But for early media we use 180/PRACK to offer and answer the early media > just before > > the Invite/200 interaction is completed. > > Is this method break the Offer/Answer law? No. It works like this: INVITE (offer 1) --> <-----183 (answer 1)- <------200 OK (offer 2)-- -------ACK (answer 2)----> that is, the 200 OK is a new offer, and then SDP is present in the ACK with an answer. This is different from the "common" practice today for early media, which has the 183 as an anwer, with a 200 OK that repeats the same SDP. I believe there will largely be backwards compatibility. If the UAS does the "common" thing when talking to an element compliant to bis/o-a, it will send SDP in the ACK, but so long as its not different from the offer in the INVITE, there won't be any issues. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 4 10:50: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 KAA26345 for ; Mon, 4 Feb 2002 10:50:42 -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 KAA10636; Mon, 4 Feb 2002 10:50: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 KAA10602 for ; Mon, 4 Feb 2002 10:49:58 -0500 (EST) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26310 for ; Mon, 4 Feb 2002 10:49:50 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g14FnqZ08660 for ; Mon, 4 Feb 2002 17:49:52 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Feb 2002 17:49:47 +0200 Received: from mgw.research.nokia.com ([172.21.33.76]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Feb 2002 17:49:43 +0200 Received: from agni.research.nokia.com (agni.research.nokia.com [172.21.40.24]) by mgw.research.nokia.com (8.9.3/8.9.3) with ESMTP id RAA28455; Mon, 4 Feb 2002 17:49:43 +0200 (EET) Received: (from ppessi@localhost) by agni.research.nokia.com (8.11.6/8.11.2) id g14FrMR09954; Mon, 4 Feb 2002 17:53:22 +0200 To: Gonzalo Camarillo , mmusic@ietf.org Cc: Hesham Soliman (ERA) , Pekka Savola , ipng@sunroof.eng.sun.com, seancolson@yahoo.com Subject: Re: [MMUSIC] RE: Last Call: Support for IPv6 in SDP to Proposed Standard References: <4DA6EA82906FD511BE2F00508BCF053802D4D0DD@Esealnt861.al.sw.ericsson.se> <3C59AA98.AEA5FAE5@lmf.ericsson.se> <3C59AA98.AEA5FAE5@lmf.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: <3C59AA98.AEA5FAE5@lmf.ericsson.se> Date: 04 Feb 2002 17:53:22 +0200 Message-ID: Lines: 121 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-OriginalArrivalTime: 04 Feb 2002 15:49:43.0986 (UTC) FILETIME=[908A3920:01C1AD93] 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 Gonzales, In message <3C59AA98.AEA5FAE5@lmf.ericsson.se> Gonzalo Camarillo writes: >Therefore, comments about the actual format are very welcome. Other >comments are interesting for other documents, but I do not think the >IESG has to be involved in such a discussion until those documents are >done. Would it be impossible (or too late) to align your spec with the updated format in sdp-new-04? It fixes the errors in your ABNF and it is mostly consistent with the syntax in RFC 2327. I have cut and pasted relevant ABNF from sdp-new-04 and RFC 2327 (FQDN and TTL are from old SDP) below. It is not strictly compatible with RFC 2327 as it fixes a bug with multicast-address rule (which could have more than 4 octets in RFC 2327): --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- 3. Syntax RFC2373 [1] gives an ABNF for the text representation of IPv6 addresses in Appendix B. RFC2732 [3] covers the text representation of IPv6 addresses when used within a URL. Using the ABNF described in these documents, the following updated ABNF for SDP is proposed. connection-address = multicast-address | addr multicast-address = addr "/" ttl [ "/" integer ] ;IPv4 multicast addresses must be in the range ;224.0.0.0 to 239.255.255.255 ;IPv6 multicast addresses must begin with the byte FF ;or include an IPv4 multicast address ttl = decimal-uchar addr = FQDN | unicast-address unicast-address = IP4-address | IP6-address FQDN = 4*(alpha-numeric|"-"|".") ;fully qualified domain name as specified in RFC1035 ; IP4-address, IP6-address: From RFC 2373 IP6-address = hexpart [ ":" IP4-address ] IP4-address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG uri = URI-reference ; defined in RFC2396/2732 ; decimal-uchar, integer, and alpha-numeric are defined in RFC2327 -->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8-- You could also discuss how TTL should be used with IPv6 addresses. While TTL is nice thing and makes it easy to recognize multicast addresses, it is not compatible with RFC2327 syntax. So, I propose something like following: --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<-- 4.2 IPv6 and Multicast Addresses The IPv6 multicast addresses have the following format: | 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+ A 8-bit prefix of all ones at the start of the address identitifies a multicast address. The text representation of the IPv6 multicast addresses begins always with a four-digit hex segment starting with "FF". Following the prefix are three reserved bits, initialized to zero, and a flag indicating how the address has been assigned. In text representation, the third hex-digit indicates if the multicast address is well-known (even digit) or transient (odd digit). The following four bits, scop, indicates the scope of the multicast address. The scop is the fourth hex-digit in the text representation. There is no TTL in IPv6, but the scope and group ID together identifies the multicast group. For multicast addresses mapped uniquely to IEEE 802 MAC addresses, the next 80 bits or 20 hex digits are reserved and must be zero. The last 32 bits identitifies the group within given scope. | 8 | 4 | 4 | 80 bits | 32 bits | +------ -+----+----+---------------------------+-----------------+ |11111111|flgs|scop| reserved must be zero | group ID | +--------+----+----+---------------------------+-----------------+ 4.2.1 Using TTL with IPv6 Multicast Address Conferences using an IPv6 multicast connection address SHOULD also have a time to live (TTL) value present in addition to the multicast address. The TTL and the IPv4 address together define the scope with which multicast packets sent in this conference will be sent. When an IPv4-compatible-IPv6 or IPv4-mapped-IPv6 address is used, TTL value MUST be in the range 0-255. When an IPv6 multicast connection address is used, a TTL value of 0 SHOULD is included. The TTL for the session is appended to the address using a slash as a separator. Examples are: c=IN IP6 FF1E::172A:1E24/0 c=IN IP6 ::233.42.30.36/16 -->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8---->8-- Pekka _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 4 13:18: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 NAA01968 for ; Mon, 4 Feb 2002 13:18: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 NAA21529; Mon, 4 Feb 2002 13:17:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21494 for ; Mon, 4 Feb 2002 13:17:45 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01961 for ; Mon, 4 Feb 2002 13:17:42 -0500 (EST) SUBJECT: Fw: Re: [MMUSIC] updated offer/answer draft DATE: 04 Feb 2002 18:17:43 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 4 Feb 2002 18:17:44 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA21495 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 Hi Folks, It is specified in the section 6.1 of the new offer-answer draft that recvonly stream MAY indicate additional media formats, not listed in the offer, that the answerer is willing to receive with. Is it allowed in sendrecv streams? ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 4 21:20:41 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 VAA10160 for ; Mon, 4 Feb 2002 21:20:41 -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 VAA15558; Mon, 4 Feb 2002 21:20: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 VAA15527 for ; Mon, 4 Feb 2002 21:20:05 -0500 (EST) Received: from murrow2k1.real.com (murrow2k1.real.com [207.188.7.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10154 for ; Mon, 4 Feb 2002 21:20:01 -0500 (EST) Received: from ROBLA350 ([172.23.100.116]) by murrow2k1.real.com (8.12.2/8.12.2) with ESMTP id g152K2sJ029714; Mon, 4 Feb 2002 18:20:03 -0800 Date: Mon, 4 Feb 2002 18:21:59 -0800 (Pacific Standard Time) From: Rob Lanphier To: Jonathan Sergent cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) In-Reply-To: <20020125144011.F20341@vernors> 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 Hi Jonathan, I've floated your proposal around here at RN, and I think we agree with most of what you lay out. More inline. On Fri, 25 Jan 2002, Jonathan Sergent wrote: > (a) PLAY should only be allowed for playing everything that was SETUP. > It should be an error to PLAY a stream URL on a session where multiple > stream URLs have been SETUP. Agreed. > (b) PAUSE should then be modified so that only PAUSE of the URL that was > PLAYed is legal, to remove the other half of the "mute" functionality. Also agreed. > (b) New methods: MUTE and UNMUTE, to reintroduce mute functionality > -- Can be done as an extension rather than part of 2326 > -- Either way, it should be optional I think an extension is certainly the safer route to take. If it's part of a new RTSP draft, it might not be on the same interop timescale as the rest of the draft. Since it'd be an optional extension, it makes sense as an extension. > -- Can be detected via OPTIONS (or by trying and letting it fail; > but the server shouldn't close the connection or session for an > unknown method) since they are new methods Agreed. That's part of what we like about this. > -- This could also be done with a pre-defined parameter instead of > a new method. This seems new and different enough to justify a new method. It's not like method names are any more expensive than headers, and the semantics are such that it is different. > -- Can only be used on a stream URL which has been SETUP for the > same session. Error to use it on an aggregate URL. > -- "Mutedness" of a stream is not reset by doing PAUSE or PLAY > -- MUTE can be sent before PLAY and will persist Agreed on all points. One thing we might want to consider is whether or not it is/can be an error to *not* SETUP one of the streams in an aggregate session. In my book, that's fine...the stream is just MUTEd by default. If we allow this, though, then we have to consider the possibility of a SETUP after PLAY (and whether or not that's an implicit UNMUTE). > -- Range header can be used to schedule MUTE and UNMUTE operations. > If queueing is to be performed, MUTE and UNMUTE requests are > queued the same way that PLAY requests are. Hee hee....assuming we can agree on how PLAY requests get queued. :) In general, this is a good principle. > (c) Deprecate the usage of PLAY with no range header on a playing stream > as a liveness ping. Allow it to remain a no-op for a playing stream, > but suggest that clients use a SET_PARAMETER or an OPTIONS > which mentions the session identifier as a keep-alive. Could introduce > a PING method, but I think this is unnecessary. I agree with Magnus on this. We could continue to "harmlessly" overload other methods, but that's the same trap that got us where we are. It seems that a PING would be so well understood as a method, and so easily implemented, that we should just add it. Where I disagree with Magnus is that I don't think we can require this from clients and servers, but we can require the following: 1. Implementations MUST not disconnect when rejecting this method (or any well-formed new method) 2. PING senders MUST be prepared to accept "405 Method not allowed", and treat that as an acceptable liveness check. > (d) Queued play should either be removed or be made optional. > If the server does not do queued play, then PLAY requests with > range headers are invalid while the server is playing and should > generate "method not valid in this state". Agreed. Rob _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 10:40:06 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 KAA04441 for ; Tue, 5 Feb 2002 10:40: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 KAA07549; Tue, 5 Feb 2002 10:39:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07513 for ; Tue, 5 Feb 2002 10:39:45 -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 KAA04393 for ; Tue, 5 Feb 2002 10:39:42 -0500 (EST) From: lieve.bos@alcatel.be Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g15FdAD19970; Tue, 5 Feb 2002 16:39:10 +0100 (MET) Received: from alcatel.be ([138.203.33.41]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002020516390848:2102 ; Tue, 5 Feb 2002 16:39:08 +0100 Message-ID: <3C5FFC99.883289AD@alcatel.be> Date: Tue, 05 Feb 2002 16:39:05 +0100 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org Cc: igor.curcio@nokia.com, cabo@tzi.org, jo@tzi.org, dku@tzi.org X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/05/2002 16:39:08, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/05/2002 16:39:10, Serialize complete at 02/05/2002 16:39:10 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Question about QoS parameters in SDPng 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, 1) Draft-ietf-mmusic-sdpng-req-01.txt states that there is a requirement from the IETF Multiparty Multimedia Session Control (MMUSIC) working group to specify additional QoS parameters for SDPng. Which QoS parameters did the authors have in mind? And how would they be used? Has there been any work on the topic of QoS parameters in SDPng lately? Personally I have some ideas about how it could work but I would like to open the discussion to everyone. 2) Realistically speaking by when will the features for SDPng be freezed? In the last version of the MMUSIC charter sent around on the mailinglist I found 'Apr 02: Submit 'SDPng base spec' to IESG for publication as Proposed Standard. Is this date feasible? If not, could someone comment on a new feasible date? By when should the features be frozen in order to get them included in the SDPng base spec? Thanks, Lieve _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 10:44: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 KAA04796 for ; Tue, 5 Feb 2002 10:44:58 -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 KAA07905; Tue, 5 Feb 2002 10:43: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 KAA07869 for ; Tue, 5 Feb 2002 10:43:43 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04705 for ; Tue, 5 Feb 2002 10:43:39 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g15FheC02607; Tue, 5 Feb 2002 16:43:40 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA12757; Tue, 5 Feb 2002 16:43:40 +0100 Message-ID: <3C5FFDAB.6AC2A419@era.ericsson.se> Date: Tue, 05 Feb 2002 16:43:39 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Lanphier CC: Jonathan Sergent , "mmusic@ietf.org" Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) 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 Hi, See comments below. Rob Lanphier wrote: > > -- Can only be used on a stream URL which has been SETUP for the > > same session. Error to use it on an aggregate URL. > > -- "Mutedness" of a stream is not reset by doing PAUSE or PLAY > > -- MUTE can be sent before PLAY and will persist > > Agreed on all points. One thing we might want to consider is whether or > not it is/can be an error to *not* SETUP one of the streams in an > aggregate session. In my book, that's fine...the stream is just MUTEd by > default. If we allow this, though, then we have to consider the > possibility of a SETUP after PLAY (and whether or not that's an implicit > UNMUTE). > My opinion is that we must allow to setup a single media from a presentation containing multiple medias, as this is non-aggregate control. Some clients may desire to do this in certain presentations. I believe disallowing doing single stream control with play and pause in an aggregated session, i.e. a session with two or more different medias setuped, still cleans up this a lot. Then introducing an extension for MUTE and UNMUTE giving a that functionality. This seems to provide all functionality that I can think of. I do have a question regarding aggregated control. Is it allowed to setup two medias coming from different presentations? I think this is a special case of creating aggregates from medias in individual files and not in any container files. > > (c) Deprecate the usage of PLAY with no range header on a playing stream > > as a liveness ping. Allow it to remain a no-op for a playing stream, > > but suggest that clients use a SET_PARAMETER or an OPTIONS > > which mentions the session identifier as a keep-alive. Could introduce > > a PING method, but I think this is unnecessary. > > I agree with Magnus on this. We could continue to "harmlessly" overload > other methods, but that's the same trap that got us where we are. It > seems that a PING would be so well understood as a method, and so easily > implemented, that we should just add it. > Where I disagree with Magnus is that I don't think we can require this > from clients and servers, but we can require the following: > > 1. Implementations MUST not disconnect when rejecting this method (or any > well-formed new method) > 2. PING senders MUST be prepared to accept "405 Method not allowed", and > treat that as an acceptable liveness check. > I believe that point 2 is in error. I agree that it must be ready to accept 405 or 501 Not Implemented. But it can't treat it as a an acceptable keep alive mechanism. The session id probably never was interpreted and the timer not reset. I can't see any reasons not to mandate PING for all implementations. When most implementations support the new spec keep alive and livness checks can be done in both directions (client<-->server). I do understand that a fallback mechanism should be specified. In my opinion the livness check should be done in the following way: 1. Try required method PING. If a old non upgraded implementation is used, on error message try both 2. 2a. Try Options with session ID. I am uncertain if most implementations support this? The problem is that you don't know if the session timer was reset. 2b. If SET_PARAMETER with session ID is implemented it should also work. But as this is outside the minimal implementation it is uncertain if it will work. 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 17:04: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 RAA21125 for ; Tue, 5 Feb 2002 17:04: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 RAA05176; Tue, 5 Feb 2002 17:04:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05133 for ; Tue, 5 Feb 2002 17:04:23 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21092 for ; Tue, 5 Feb 2002 17:04:19 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g15M4O6Y014873; Tue, 5 Feb 2002 17:04:27 -0500 (EST) Message-ID: <3C6056BC.A38160A8@dynamicsoft.com> Date: Tue, 05 Feb 2002 17:03:40 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org Subject: Re: Fw: Re: [MMUSIC] updated offer/answer 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 Roman Shpount wrote: > > Hi Folks, > > It is specified in the section 6.1 of the new offer-answer draft that > recvonly stream MAY indicate additional media formats, not listed in the > offer, that the answerer is willing to receive with. Is it allowed in > sendrecv streams? This is a good question. In the sendrecv case, if the answerer adds a codec X, it cant ever send with X, since it doesn't know if its supported by the other side. Thus, its not actually being used as sendrecv, and therefore, does not belong in the list as a valid sendrecv codec. That is different for recvonly. I could be convinced to remove this bit in the case of recvonly, to make things simple and concise. The answer is always a subset, period. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 18:06: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 SAA22741 for ; Tue, 5 Feb 2002 18:06:38 -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 SAA07760; Tue, 5 Feb 2002 18:06:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07731 for ; Tue, 5 Feb 2002 18:06:17 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22727 for ; Tue, 5 Feb 2002 18:06:14 -0500 (EST) SUBJECT: Re: Re: Fw: Re: [MMUSIC] updated offer/answer draft DATE: 05 Feb 2002 23:06:13 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 5 Feb 2002 23:06:14 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA07732 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 The reasoning behind this question is the same as the reasoning used to justify and support different payload type numbers in reply to the sendrecv offer. If we follow this logic, a called party gets an offer, which specifies what the calling party is willing to receive and replies with an answer that lists everything that called party is willing to receive for each of the offered streams. Those two offers must intersect as far as capabilities are concerned but both can include additional formats and use different payload types. Actually, what would be ideal is to have an ability to send two independent lists of formats that application is willing to send and to receive on the sendrecv stream. This way, for instance, application can specify its codec preferences for asymmetric connections. Roman Shpount ------ Original message ------ >From: Jonathan Rosenberg >Subject: Re: Fw: Re: [MMUSIC] updated offer/answer draft >Date: 05 Feb 02, 10:03 PM >To: Roman Shpount >Cc: mmusic@ietf.org Roman Shpount wrote: > > Hi Folks, > > It is specified in the section 6.1 of the new offer-answer draft that > recvonly stream MAY indicate additional media formats, not listed in the > offer, that the answerer is willing to receive with. Is it allowed in > sendrecv streams? This is a good question. In the sendrecv case, if the answerer adds a codec X, it cant ever send with X, since it doesn't know if its supported by the other side. Thus, its not actually being used as sendrecv, and therefore, does not belong in the list as a valid sendrecv codec. That is different for recvonly. I could be convinced to remove this bit in the case of recvonly, to make things simple and concise. The answer is always a subset, period. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 21:14:21 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 VAA27854 for ; Tue, 5 Feb 2002 21:14: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 VAA17297; Tue, 5 Feb 2002 21:14:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17263 for ; Tue, 5 Feb 2002 21:14:05 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA27850 for ; Tue, 5 Feb 2002 21:14:01 -0500 (EST) DATE: 06 Feb 2002 02:14:04 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 6 Feb 2002 02:14:04 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA17264 Subject: [MMUSIC] Functionality missing in offer/answer 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 Hi Folks, From my point of view the following functionality is missing in offer/answer: 1. Ability to authorize media streams SDP, due to its roots as a conference description protocol, does not specify any information about media stream origination address or any information that can be used to determine whether media was originated by a valid source. Since an end point or a firewall has no information to authorize media streams, deploying any offer/answer communication systems on public networks presents an unjustified security risk. Any party on the same network can scan a host for open UDP ports and send series of RTP packets that will interrupt all the RTP streams terminated by this host. As far as I am aware current implementations are trying to avoid this problem by only accepting media from IP address specified as destination address for the media stream. This contradicts the current offer/answer draft and does not really solve the security problem, since origination IP address can be spoofed. The other solution is to store SDES and origination IP from the first media packets that pass probation and ignore all subsequent packets from the different IP or with different SDES. This solution is more secure, but contradicts current RTP specifications. Solution that I propose is to provide a way to specify SDES and/or origination IP in the offer/answer SDP. Unfortunately, this solution does not interoperate well with early media, since it will cause all the early media packets to be received but ignored. 2. Causing the other party of an already established session to send a new offer This functionality is often needed when functionality similar to SIP REFER method is implemented using Back-to-Back SIP User Agent and re-INVITES. I believe this issue was brought up already during the discussion of the original offer/answer. Consider the following scenario: 1) a session is established through a Back-to-Back SIP User Agent between users A and B. 2) a Back-to-Back SIP User Agent needs to According to current specifications there is no reliable way to implement this scenario. If a new offer is received by a Back-to-Back SIP User Agent from C there is no way to ensure it will satisfy any of the requirements for the session description during session modification (not decreasing number of streams etc). On the other hand if the description of the session between A and B is used as offer to C it might be rejected due to the fact that media handling capabilities of A and C might not intersect (even though communications between C and B are possible). Additionally, knowledge of potential capabilities is insufficient to solve this problem, since the real offer (with valid destination ports and addresses) needs to be given to one of the parties and since this offer needs to compatible with the current session. The proposed solution to this problem is to cause one of the parties to send an offer that will be on one hand compatible with the current session, but on the other hand will include all the end point's desired media capabilities. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 5 21:25: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 VAA28067 for ; Tue, 5 Feb 2002 21:25:37 -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 VAA17658; Tue, 5 Feb 2002 21:25:11 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA17622 for ; Tue, 5 Feb 2002 21:25:10 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28060 for ; Tue, 5 Feb 2002 21:25:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.41]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g162PG6Y015158; Tue, 5 Feb 2002 21:25:16 -0500 (EST) Message-ID: <3C6093E0.90E957CB@dynamicsoft.com> Date: Tue, 05 Feb 2002 21:24:32 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org Subject: Re: [MMUSIC] Functionality missing in offer/answer 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 inline. Roman Shpount wrote: > > Hi Folks, > > >From my point of view the following functionality is missing in > offer/answer: > > 1. Ability to authorize media streams > > SDP, due to its roots as a conference description protocol, does not > specify any information about media stream origination address or any > information that can be used to determine whether media was originated > by a valid source. Since an end point or a firewall has no information > to authorize media streams, deploying any offer/answer communication > systems on public networks presents an unjustified security risk. Any > party on the same network can scan a host for open UDP ports and send > series of RTP packets that will interrupt all the RTP streams terminated > by this host. > > As far as I am aware current implementations are trying to avoid this > problem by only accepting media from IP address specified as destination > address for the media stream. This contradicts the current offer/answer > draft and does not really solve the security problem, since origination > IP address can be spoofed. The other solution is to store SDES and > origination IP from the first media packets that pass probation and > ignore all subsequent packets from the different IP or with different > SDES. This solution is more secure, but contradicts current RTP > specifications. > > Solution that I propose is to provide a way to specify SDES and/or > origination IP in the offer/answer SDP. Unfortunately, this solution > does not interoperate well with early media, since it will cause all the > early media packets to be received but ignored. That provides pretty much no security, since its totally spoofable. The right way is to use SRTP. It will provide true cryptographic authentication. You will be able to signal SRTP usage in SDP, and thus, in offer/answer, and have proper security. > > 2. Causing the other party of an already established session to send a > new offer > > This functionality is often needed when functionality similar to SIP > REFER method is implemented using Back-to-Back SIP User Agent and > re-INVITES. I believe this issue was brought up already during the > discussion of the original offer/answer. Consider the following > scenario: > > 1) a session is established through a Back-to-Back SIP User Agent > between users A and B. > > 2) a Back-to-Back SIP User Agent needs to > > According to current specifications there is no reliable way to > implement this scenario. If a new offer is received by a Back-to-Back > SIP User Agent from C there is no way to ensure it will satisfy any of > the requirements for the session description during session modification > (not decreasing number of streams etc). On the other hand if the > description of the session between A and B is used as offer to C it > might be rejected due to the fact that media handling capabilities of A > and C might not intersect (even though communications between C and B > are possible). > > Additionally, knowledge of potential capabilities is insufficient to > solve this problem, since the real offer (with valid destination ports > and addresses) needs to be given to one of the parties and since this > offer needs to compatible with the current session. > > The proposed solution to this problem is to cause one of the parties to > send an offer that will be on one hand compatible with the current > session, but on the other hand will include all the end point's desired > media capabilities. This is covered thorougly in draft-ietf-sip-rfc2543bis-07. It has nothing to do with offer answer. O/A doesn't tell you how or when you send offers, only what the exchange needs to be when you do. O/A also doesn't tell you how to formulate offers, only provides guidelines for how you can. In bis-07, it explicilty mentions in Section 14.2, lines 2278 - 2285, which read: A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer which 2279 updates an existing session, as described in [1] in the case of SDP. Specifically, this means that it SHOULD 2280 include as many media formats and media types that the UA is willing to support. The UAS MUST ensure 2281 that the session description overlaps with its previous session description in media formats, transports, or 2282 other parameters that require support from the peer. This is to avoid the need for the peer to reject the session 2283 description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid 2284 session description, and then send a BYE to terminate the session. 2285 bis has always allowed one side to "prod" the other into making the offer by sending an INVITE without SDP, and that text still exists in bis-07. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 6 11:53: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 LAA25595 for ; Wed, 6 Feb 2002 11:53: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 LAA12598; Wed, 6 Feb 2002 11:52:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12567 for ; Wed, 6 Feb 2002 11:52:32 -0500 (EST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25586 for ; Wed, 6 Feb 2002 11:52:27 -0500 (EST) Received: from phys-ha2mpkb.Eng.Sun.COM ([129.146.16.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13955; Wed, 6 Feb 2002 09:52:30 -0700 (MST) Received: from sun.com (vpn-129-150-4-93.EBay.Sun.COM [129.150.4.93]) by phys-ha2mpkb.Eng.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.0) with ESMTP id IAA10522; Wed, 6 Feb 2002 08:52:29 -0800 (PST) Message-ID: <3C615EDF.3000306@sun.com> Date: Wed, 06 Feb 2002 11:50:39 -0500 From: Aravind Narasimhan 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: Magnus Westerlund CC: Jonathan Sergent , mmusic@ietf.org Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) References: <20020125144011.F20341@vernors> <3C551C14.68F2EB5F@era.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Please see my comments inline: [snip] >>Scenario #6: >>Initial connection setup, followed by: >>-------------------------------------------------------------------- >>C->S >>PLAY rtsp://host/a/ RTSP/1.0 >>Cseq: 4 >>Session: ZZEfpZ0zxK5 >>Range: npt=0-30 >> >>-------------------------------------------------------------------- >>S->C (time = t) >>RTSP/1.0 200 OK >>Cseq: 4 >>Session: ZZEfpZ0zxK5 >>RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914, >> url=rtsp://host/a/c;seq=16778;rtptime=1946900992 >> >>-------------------------------------------------------------------- >>C->S (time = t + 1) >>PLAY rtsp://host/a/ RTSP/1.0 >>Cseq: 5 >>Session: ZZEfpZ0zxK5 >>Range: npt=45-60 >> >>-------------------------------------------------------------------- >>S->C >>RTSP/1.0 200 OK >>Cseq: 5 >>Session: ZZEfpZ0zxK5 >>RTP-Info: url=rtsp://host/a/b;seq=16664;rtptime=660914, >> url=rtsp://host/a/c;seq=18578;rtptime=1949600992 >> >>-------------------------------------------------------------------- >> >>This is normal queued play. The server plays the presentation for the >>first thirty seconds, then immediately jumps 15 seconds ahead and plays >>the last fifteen seconds, then pauses. >> > >I would like us to consider the language we are using. I would not call it >pauses after it has played the last 15 seconds. Rather I would call it halt or >stops. The reason is the use of the word pause implies that the client sent a >pause, which obviously not is the case. > I dont think you can use the word "halt". Section 10.6 of the RFC uses halt in its explantion of the PAUSE functionality: Section 10.6 The PAUSE request causes the stream delivery to be interrupted (halted) temporarily. If the request URL names a stream, only playback and recording of that stream is halted. The word is too overloaded. The defintion of a PLAY with range headers uses PAUSE in it explanation too. Section 10.5 After playing the desired range, the presentation is automatically paused, as if a PAUSE request had been issued. obviously "halt" and "pause" were meant to be used interchangeably in the RFC. I do think that clearer terminology is warrented in a newer rev. of the standard. >And the difference is rather obvious if >you would send another play without range after the stream has halted. If it has >halted the play starts from the beginning of stream (npt=0-). If it was paused >it would continue where it has paused. > I dont think that RFC draws this disctinction at present. >>I think these changes are warranted to clean this up: >> >>(a) PLAY should only be allowed for playing everything that was SETUP. >> It should be an error to PLAY a stream URL on a session where multiple >> stream URLs have been SETUP. >>(b) PAUSE should then be modified so that only PAUSE of the URL that was >> PLAYed is legal, to remove the other half of the "mute" functionality. >>(b) New methods: MUTE and UNMUTE, to reintroduce mute functionality >> -- Can be done as an extension rather than part of 2326 >> -- Either way, it should be optional >> -- Can be detected via OPTIONS (or by trying and letting it fail; >> but the server shouldn't close the connection or session for an >> unknown method) since they are new methods >> -- This could also be done with a pre-defined parameter instead of >> a new method. >> -- Can only be used on a stream URL which has been SETUP for the >> same session. Error to use it on an aggregate URL. >> -- "Mutedness" of a stream is not reset by doing PAUSE or PLAY >> -- MUTE can be sent before PLAY and will persist >> -- Range header can be used to schedule MUTE and UNMUTE operations. >> If queueing is to be performed, MUTE and UNMUTE requests are >> queued the same way that PLAY requests are. >>(c) Deprecate the usage of PLAY with no range header on a playing stream >> as a liveness ping. Allow it to remain a no-op for a playing stream, >> but suggest that clients use a SET_PARAMETER or an OPTIONS >> which mentions the session identifier as a keep-alive. Could introduce >> a PING method, but I think this is unnecessary. >>(d) Queued play should either be removed or be made optional. >> If the server does not do queued play, then PLAY requests with >> range headers are invalid while the server is playing and should >> generate "method not valid in this state". >> > >This behavior with the mute functionality looks fine. To my understanding the >functionality which is removed is the possibility to change the synchronization >between media, as this is possible with multiple single media sessions, i.e. >non-aggregated control, I don't see a problem. > one thing that needs to be addressed is the question of muting all the streams in a session. Likewise the question of muting a stream before playback has begun is important to consider. > > >I would argue for a mandatory to implement method PING in both servers and >clients. This prevents overloading of functionality which created this mess in >the first place. > Agreed. Aravind _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 6 15:19: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 PAA00375 for ; Wed, 6 Feb 2002 15:19:56 -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 PAA24695; Wed, 6 Feb 2002 15:19: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 PAA24664 for ; Wed, 6 Feb 2002 15:19:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00356 for ; Wed, 6 Feb 2002 15:19:28 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g16KJZ6Y015713; Wed, 6 Feb 2002 15:19:35 -0500 (EST) Message-ID: <3C618FAA.F91BD2D@dynamicsoft.com> Date: Wed, 06 Feb 2002 15:18:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org Subject: Re: Fw: Re: [MMUSIC] updated offer/answer 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 Roman Shpount wrote: > > The reasoning behind this question is the same as the reasoning used to > justify and support different payload type numbers in reply to the > sendrecv offer. If we follow this logic, a called party gets an offer, > which specifies what the calling party is willing to receive and replies > with an answer that lists everything that called party is willing to > receive for each of the offered streams. Thats not how it works. For sendrecv streams, the caller offers what it can send and received, and same in the answer. If both sides just send what they can receive, you can't guarantee overlap. > Those two offers must intersect > as far as capabilities are concerned but both can include additional > formats and use different payload types. Actually, what would be ideal > is to have an ability to send two independent lists of formats that > application is willing to send and to receive on the sendrecv stream. > This way, for instance, application can specify its codec preferences > for asymmetric connections. That is a known limitiation of SDP we cannot fix in this draft. In a sendrecv stream, you can only specify sendrecv codecs. If you want more than that, you can use FID, and that works just fine within the offer/answer framework. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 6 16:25: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 QAA02696 for ; Wed, 6 Feb 2002 16:25:38 -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 QAA27256; Wed, 6 Feb 2002 16:25:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA27224 for ; Wed, 6 Feb 2002 16:25:16 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02676 for ; Wed, 6 Feb 2002 16:25:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA09860; Wed, 6 Feb 2002 13:25:12 -0800 (PST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00803; Wed, 6 Feb 2002 13:25:12 -0800 (PST) Received: from vernors.eng.sun.com (localhost [127.0.0.1]) by vernors.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g16LPCWF011300; Wed, 6 Feb 2002 13:25:12 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g16LPCY3011299; Wed, 6 Feb 2002 13:25:12 -0800 (PST) Date: Wed, 6 Feb 2002 13:25:11 -0800 From: Jonathan Sergent To: Rob Lanphier Cc: mmusic@ietf.org Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) Message-ID: <20020206132511.C10833@vernors> References: <20020125144011.F20341@vernors> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from robla@real.com on Mon, Feb 04, 2002 at 06:21:59PM -0800 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 Sorry it took so long for me to respond. I have been out of reach of email... On Mon, Feb 04, 2002 at 06:21:59PM -0800, Rob Lanphier wrote: > I think an extension is certainly the safer route to take. If it's part > of a new RTSP draft, it might not be on the same interop timescale as the > rest of the draft. Since it'd be an optional extension, it makes sense as > an extension. This sounds right. I think will want to implement it, but we don't have a client. Is there someone else interested in making this work? > Agreed on all points. One thing we might want to consider is whether or > not it is/can be an error to *not* SETUP one of the streams in an > aggregate session. In my book, that's fine...the stream is just MUTEd by > default. If we allow this, though, then we have to consider the > possibility of a SETUP after PLAY (and whether or not that's an implicit > UNMUTE). I think that not doing a SETUP is different than doing a MUTE, because the RTP session is never established, and RTCP reports cannot be exchanged, and so on. The RFC is unclear on what a SETUP means after PLAY if the SETUP is for a URL that is not already part of the session. (If it's for the same URL, then it's just a request to change the transport parameters, of course.) I think we should forbid this, because it just adds more complexity. It would make it so that you could use SETUP and TEARDOWN of individual streams to do approximately the same thing as MUTE and UNMUTE. (I would like to leave "There's More Than One Way To Do It" to the Perl people and say that this is probably not desirable for network protocols.) Since the second and further SETUP requests can be pipelined (you can send them all at once since you have the session ID after the first one), I don't think there is a latency argument for this, either. > > -- Range header can be used to schedule MUTE and UNMUTE operations. > > If queueing is to be performed, MUTE and UNMUTE requests are > > queued the same way that PLAY requests are. > > Hee hee....assuming we can agree on how PLAY requests get queued. :) Yeah. I unfortunately missed the call today so I don't know if we came to any conclusions on what to do about queued play yet. We will need to figure out a resolution for that before we could move forward with an I-D on a MUTE/UNMUTE extension, because it would come out differently... > > (c) Deprecate the usage of PLAY with no range header on a playing stream > > as a liveness ping. Allow it to remain a no-op for a playing stream, > > but suggest that clients use a SET_PARAMETER or an OPTIONS > > which mentions the session identifier as a keep-alive. Could introduce > > a PING method, but I think this is unnecessary. > > I agree with Magnus on this. We could continue to "harmlessly" overload > other methods, but that's the same trap that got us where we are. It > seems that a PING would be so well understood as a method, and so easily > implemented, that we should just add it. > > Where I disagree with Magnus is that I don't think we can require this > from clients and servers, but we can require the following: > > 1. Implementations MUST not disconnect when rejecting this method (or any > well-formed new method) > 2. PING senders MUST be prepared to accept "405 Method not allowed", and > treat that as an acceptable liveness check. Can we add PING to the base specification and still go to draft standard? I sympathize with the desire to avoid overloading, but I think it is a lot easier to just keep the current use of OPTIONS. I think we can agree that using OPTIONS as a keep-alive is not going away, and I would prefer for us to not introduce two ways of doing the same thing. On (1) I agree 100%; on (2) I think it would be a 501 Not Implemented. 405 would imply that the server understood the PING but didn't allow it. It seems like this would imply PING having failed rather than succeeded. If we have PING, I think the client should be prepared to receive one of 200, 454, or 501. I think 405 means that the method is not valid for the given URL, i.e. if you try to send a web server a POST for an ordinary HTML file. So one final question about PING is what should be done with the URL field. (I wonder the same thing about OPTIONS, though; what should the server do if you do an OPTIONS with a Session header on a URL that is not part of that session?) --jss. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 7 16:46: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 QAA10764 for ; Thu, 7 Feb 2002 16:46: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 QAA18906; Thu, 7 Feb 2002 16:45:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18875 for ; Thu, 7 Feb 2002 16:45: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 QAA10752 for ; Thu, 7 Feb 2002 16:45:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Thu, 07 Feb 2002 13:44:09 -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, 07 Feb 2002 13:44:09 -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 g17LfJ4r020405 for ; Thu, 7 Feb 2002 13:41:19 -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 16YwHu-0006Fv-00 for ; Thu, 07 Feb 2002 13:41: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, 07 Feb 2002 13:41:02 -0800 X-Spam-Status: No, hits=1.2 required=5.5 tests=NO_REAL_NAME version=2.1 X-UIDL: 12e489679deaede65aaac688b0953d08 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #20 - 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-448521 ] URLs in Rtp-Info need to be quoted (noreply@sourceforge.net) 2. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 (noreply@sourceforge.net) 3. [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem (noreply@sourceforge.net) 4. [ rtspspec-Bugs-511686 ] Timed PLAY requests has RTP-Info problem (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 17:54:15 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted Bugs item #448521, was opened at 2001-08-06 13:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194 Category: None >Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Rob Lanphier (robla) Summary: URLs in Rtp-Info need to be quoted Initial Comment: The Rtp-Info header contains URLs, but those URLs are not quoted, causing problems when the URLs contain semi-colon, equal signs and comma characters. The best way to quote URLs are by using double- quotes. Using angle-brackets has also been proposed, but using double-quotes is more likely to be compatbile with existing implementations, because other RTSP/HTTP headers use double-quote characters in similar situations. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:20 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 telecon) Proposed solution was accepted. Alternative use of semicolon and comma were considered by classified as "dangerous characters" ans would break existing implementations. ---------------------------------------------------------------------- Comment By: Henning Schulzrinne (hgschulz) Date: 2002-01-09 09:20 Message: Logged In: YES user_id=115926 URL escaping (%xx) doesn't work since you lose the distinction between syntactically significant semicolons (etc.) and just characters that were escaped in the original URL. Only comma and semicolon need to be escaped, since equal signs are not delimiters. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:26 Message: Logged In: YES user_id=3796 I should probably clarify the comments made yesterday. This is a genuine issue, but it needs to be weighed against backward-compatibility needs. Would like input from implementors on what the best solution is. We would propose the following: * We need to define the problem characters. ";" and "=" are two, there may be others * URLs MUST not be quoted when no problem characters are present in the URL. This will help maintain backwards-compatibilty with current implementations * URLs MUST be quoted when problem characters are present ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-12 14:14 Message: Logged In: YES user_id=3796 add quotes only when sending problem characters (";", "=", ",", need to think further) ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-08-07 07:21 Message: Logged In: YES user_id=3796 This is primarily to test if mail to confctrl is working ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 18:14:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 Bugs item #477404, was opened at 2001-11-01 23:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 Category: None >Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in table in chapter 12 Initial Comment: Table with RTSP headers page 45, contains the following errors?: - A session header is not required when using describe. - Proxy Authenticate is missing all values on what it is. - The transport header is specifed as required in 12.0 table, but the text in 12.39 says it MAY be included in requests and responses. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:41 Message: Logged In: YES user_id=437905 RESOLUTION: The latest SIP draft has an equivalent table. It has been recommended that we evaluate this SIP table and unless someone objects and justifies the need to make a change let's adopt the SIP draft specification version. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-22 19:47 Message: Logged In: YES user_id=3796 Here's a discrepency between the initial CVS checkin and RFC 2326 12 Header Field Definitions (Table 3): Change from: Content-Type r req. entity To: Content-Type e req. SET_PARAMETER, ANNOUNCE ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:53 Message: Logged In: YES user_id=3796 These are all good examples of what's wrong with this table. We need to do an audit of the table, and we may restructure this table for clarity. Suggestions for a new table format would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 31 Jan 2002 07:37:54 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-511233 ] Timed PLAY requests has RTP-Info problem Bugs item #511233, was opened at 2002-01-31 07:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Timed PLAY requests has RTP-Info problem Initial Comment: In a PLAY with a range header, "time=" can be used to give activation time. This request shall be responded immediately to the client. In the response the server should give synchronization data like RTP TS which will be used when the PLAY is activated sometime in the future. It is hard to impossible for the server to produce such data. If no other PLAY request is done between request time and activation it is possible to give an accurate TS and sequnce number. But if another request is activated in the time between, the given RTP TS or sequnce number will not be correct. This problem is the same that queued plays has, see bugreport #477432, but due to different reasons. One possible solution would be to introduce a SYNC method which a server can send at or slightly before activation of a queued or delayed play. This method would carry a RTP-info header and a range header, giving the information; what is playing and the synchronization information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=511233&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Fri, 01 Feb 2002 05:17:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-511686 ] Timed PLAY requests has RTP-Info problem Bugs item #511686, was opened at 2002-02-01 05:17 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=511686&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Timed PLAY requests has RTP-Info problem Initial Comment: In a PLAY with a range header, "time=" can be used to give activation time. This request shall be responded immediately to the client. In the response the server should give synchronization data like RTP TS which will be used when the PLAY is activated sometime in the future. It is hard to impossible for the server to produce such data. If no other PLAY request is done between request time and activation it is possible to give an accurate TS and sequnce number. But if another request is activated in the time between, the given RTP TS or sequnce number will not be correct. This problem is the same that queued plays has, see bugreport #477432, but due to different reasons. One possible solution would be to introduce a SYNC method which a server can send at or slightly before activation of a queued or delayed play. This method would carry a RTP-info header and a range header, giving the information; what is playing and the synchronization information. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=511686&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 Thu Feb 7 18:31: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 SAA12936 for ; Thu, 7 Feb 2002 18:31:53 -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 SAA24635; Thu, 7 Feb 2002 18:31: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 SAA24602 for ; Thu, 7 Feb 2002 18:31:28 -0500 (EST) Received: from real.com (murrow2k1.real.com [207.188.7.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12917 for ; Thu, 7 Feb 2002 18:31:25 -0500 (EST) Received: from ROBLA350 (tog-wakko3.prognet.com [207.188.29.248]) by real.com (8.12.2/8.12.2) with ESMTP id g17NVS4s016320 for ; Thu, 7 Feb 2002 15:31:28 -0800 Date: Thu, 7 Feb 2002 15:33:24 -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: Minutes from Feb 6 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 Hi all, Minutes from the last RTSP telecon are included below. The hyperlinked HTML version is available here: http://rtsp.org/2002/telecon/minutes06Feb.html Rob Rtsp Tc Minutes06 Feb2002 ------------------------------------------------------------------------ 1. Attendees <#line2> 2. Last telecon: discussed and still pending <#line11> 1. 477423 Unclearities regarding pause with range <#line12> 3. This telecon <#line23> 1. Mixing Aggregate and Non-aggregate Control <#line24> 1. MUTE and UNMUTE discussion <#line30> 2. 477400 Use of PLAY as aliveness check <#line62> 4. Process for next draft <#line89> Attendees * Anne Jones (AJ) * Anders Klemets (AK) * Colin Perkins (CP) * Magnus Westerlund (MW) * Aravind Narasimhan (AN) * David Walker (DW) * Rob Lanphier (RL) Agenda http://rtsp.org/2002/telecon/agenda06Feb.html (note: we only got down to http://rtsp.org/bug477400 - "Play without range while playing") Last telecon: discussed and still pending 477423 Unclearities regarding pause with range Bug report: http://rtsp.org/bug477423 Previous resolution: Only a single range specifier (format "value-" where "value" is a time) is allowed for pause. time="execution time in UTC" may also be used. A new example will be provided. * MW: any issues with my proposal? (see [[WWW]] Magnus' proposal ) * RL: still discussion happening at RN * AN: agree with Magnus * RESOLVED: go with Magnus's proposal This telecon Mixing Aggregate and Non-aggregate Control see [[WWW]] the email thread * Point a) RESOLVED * First point b) RESOLVED MUTE and UNMUTE discussion * Second point b) MUTE and UNMUTE * AN: How about a MUTE that toggles * AK: How about SETUP and TEARDOWN * RL: I don't like SETUP and TEARDOWN as MUTE/UNMUTE * AN: spirit of orig RFC was that PAUSE doesn't change anything but whether packets are flowing * AK: SETUP/TEARDOWN may be appropriate when bandwidth reservation is involved * NEW ISSUE: should SETUP be allowed after a PLAY in the same session * NEW ISSUE: should TEARDOWN function on individual streams in a session * RL: back on MUTE/UNMUTE * AN: should consider MUTE as toggle * AK: client or server could become confused * MW: I like MUTE/UNMUTE * AK: can't add new methods to base spec * CP: depends on what path we want to go * RL: rather not * ...cycle back to proposed * MW: PING may need a separate thing * RL: MUTE/UNMUTE as separate spec * CP: depends on whether or not it's required * RL: I think it's optional * MW: really good functionality * RL: should it be required? * MW: should leave it as a pending issue * CP: write up as separate spec, and then discuss how it should go * AN: PAUSE is optional * AK: Can be done other ways. w/PAUSE * MW: Can't do this with agg control * AK: still, there are apps that don't need MUTE * RESOLVED: separate draft * ACTION ITEM: Call for authors on MUTE proposed. AN is tentatively signed up 477400 Use of PLAY as aliveness check * Point C) (same as http://rtsp.org/bug477400) * AK: I don't think PING command is necessary. It breaks old implementations. 3GPP already uses OPTIONS anyway * MW: want to remove overloaded methods * RL: perhaps OPTIONS with option to switch to PING * MW: 3GPP might be able to get PING method * AK: wouldn't build something that relies on RTCP * MW: some cases, sure. PING should be 50-80 bytes, which is small enough * AK: What does PING with * mean? * RL: PING with * is a single hop mechanism. PING with host (and no resource) shoud be legal as well. That would be end-to-end * AN: perhaps session id in same way as PLAY * MW: need proposal * AK: aggregate session ids in PING method with comma sep list * MW: changing session header semantics is dangerous * RESOLVED: PING writeup will be done as part of next RTSP draft...continue discussion on mailing list * AK: Using PLAY with no range is still useful as a means of getting RTP-info * AN: we don't send it from our server * MW: state machine needs to be clarified * AN: play without range is start where left off * AN: need to clarify what PAUSE means * MW: will log issue on PLAY/PAUSE semantics * AK: need both Range header and RTP-info * AN: could start playback from pause point at the end of a range * MW: this is broken * AK: wouldn't mind seeing this go away * RESOLVED: deprecate PLAY w/o range as ping method Process for next draft * Prior to Feb 20 telecon: draft ready for group review * Feb 20: review on telecon * Prior to Feb 22: submit using standard I-D process. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 8 15:56:33 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 PAA24455 for ; Fri, 8 Feb 2002 15:56:33 -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 PAA04774; Fri, 8 Feb 2002 15:56: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 PAA04741 for ; Fri, 8 Feb 2002 15:55:59 -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 PAA24431 for ; Fri, 8 Feb 2002 15:55:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Fri, 08 Feb 2002 12:54:19 -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); Fri, 08 Feb 2002 12:54:19 -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 g18KqkFe015959 for ; Fri, 8 Feb 2002 12:52:46 -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 16ZI0g-000849-00 for ; Fri, 08 Feb 2002 12:52:42 -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: Fri, 08 Feb 2002 12:52:42 -0800 X-Spam-Status: No, hits=1.2 required=5.5 tests=NO_REAL_NAME version=2.1 X-UIDL: cc0e86f0d602648d50edfe6c275667df To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #21 - 9 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-477404 ] Errors in table in chapter 12 (noreply@sourceforge.net) 2. [ rtspspec-Bugs-513737 ] Unclarities when doing resetup (noreply@sourceforge.net) 3. [ rtspspec-Bugs-513753 ] RTSP extensions and IANA (noreply@sourceforge.net) 4. [ rtspspec-Bugs-513758 ] Proxy-Require clarification (noreply@sourceforge.net) 5. [ rtspspec-Bugs-513787 ] Allow capability negotiations (noreply@sourceforge.net) 6. [ rtspspec-Bugs-513875 ] Play when in state ready after playing (noreply@sourceforge.net) 7. [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative (noreply@sourceforge.net) 8. [ rtspspec-Bugs-513888 ] RTSP and NAT (noreply@sourceforge.net) 9. [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 05:20:08 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 Bugs item #477404, was opened at 2001-11-01 23:22 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 Category: None Group: Fix for DS - Large task Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in table in chapter 12 Initial Comment: Table with RTSP headers page 45, contains the following errors?: - A session header is not required when using describe. - Proxy Authenticate is missing all values on what it is. - The transport header is specifed as required in 12.0 table, but the text in 12.39 says it MAY be included in requests and responses. ---------------------------------------------------------------------- >Comment By: Magnus Westerlund (magwes) Date: 2002-02-06 05:20 Message: Logged In: YES user_id=302620 The table is also missing the location header. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:41 Message: Logged In: YES user_id=437905 RESOLUTION: The latest SIP draft has an equivalent table. It has been recommended that we evaluate this SIP table and unless someone objects and justifies the need to make a change let's adopt the SIP draft specification version. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-22 19:47 Message: Logged In: YES user_id=3796 Here's a discrepency between the initial CVS checkin and RFC 2326 12 Header Field Definitions (Table 3): Change from: Content-Type r req. entity To: Content-Type e req. SET_PARAMETER, ANNOUNCE ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:53 Message: Logged In: YES user_id=3796 These are all good examples of what's wrong with this table. We need to do an audit of the table, and we may restructure this table for clarity. Suggestions for a new table format would be appreciated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477404&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 05:26:26 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513737 ] Unclarities when doing resetup Bugs item #513737, was opened at 2002-02-06 05:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Unclarities when doing resetup Initial Comment: Setup is used to change transport parameters of a already setuped stream. What happends if the new SETUP contains errors? Except of responding with an error message, what happends to the session and transport state? It should be clarified in the specification. Which of the following alternatives are correct? 1. Keep the old setting and states as if the second SETUP never happend. 2. Invalidate the media in the session until a correct setup has happend. To me case 1 seems more natural but will require more from the server. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513737&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 06:05:32 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513753 ] RTSP extensions and IANA Bugs item #513753, was opened at 2002-02-06 06:05 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194 Category: None Group: Fix for Draft Standard Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: RTSP extensions and IANA Initial Comment: Today the RFC 2326 talks about extensions to RTSP and also has a number of headers that uses parameters. In the next version the following clarifications should be done: - Setup a IANA register for RTSP parameters. - Rules how to register different types of parameters. - What type of documents that are needed for extending RTSP. IANA registering of parameters. IETF RFC for new headers(?), methods and future protocol versions. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513753&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 06:16:49 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513758 ] Proxy-Require clarification Bugs item #513758, was opened at 2002-02-06 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513758&group_id=23194 Category: General Group: Fix for DS - Typo/Thinko Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Proxy-Require clarification Initial Comment: Today the proxy-require method says that the server should treat the proxy-require header identically as require. I don't understand how that mechanism work for paramters/functionallity that only the proxies should answer to. To avoid a negative acknowledgment the server must be aware of these parameters to not place them in the Unsupported header. I can't see that any proxy can modify the response as it will not know if the response comes from a proxy or a server. Can someone please clarify this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513758&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 07:33:19 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513787 ] Allow capability negotiations Bugs item #513787, was opened at 2002-02-06 07:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Allow capability negotiations Initial Comment: Today RTSP lacks the possibility to do any kind of capability/parameter negotiation or at least choices regarding media parameters. I would like to see possibilities for this in the future. My initial idea is to make a offer/answer model. This will require expanding the SETUP request to carry a message body. A message exchange could work like this. 1. C->S: Describe 2. S->C: Response with media description, SDP or in the future SDP-NG. This description contains multiple alternatives or in the case SDP-NG a complete description of the choices regarding media that the client can do. 3. Client selects its desired configuration. 4. C->S: Setup with message body with choosen configuration in SDP/SDP-NG. 5. S->C: Server either accepts or refuses the setup with the given configuration. Refusing should happend very rarely as server should not offer anything it can provide. Such solution should try to keep the difference between media parameters and transport parameters. Transport parameters should be keept in the transport header to simplify processing in proxies and firewalls. Conclusion: only media related parameters should be negotiated with the offer/answer mechanism. To my knowledge the changes required for this is to allow a message body in SETUP requests. Also rules how and to what it may be used must be specified. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513787&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 10:43:33 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513875 ] Play when in state ready after playing Bugs item #513875, was opened at 2002-02-06 10:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513875&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Play when in state ready after playing Initial Comment: A client has been playing for a while and reaches the end of either media or range. At that time the state machine goes to state ready. When in state ready a play without range is issued. The question is what happends at this point: 1. The play starts from the begining of the media. 2. If at end of media directly revert to ready, or if a play with range was the previous play continue at the end of that range. Both interpretations has been implemented. So please give your opinion on this, especially if you have arguments supporting one or the other, like usage cases. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513875&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 10:48:49 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513880 ] How to use Range when Scale is negative Bugs item #513880, was opened at 2002-02-06 10:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Nobody/Anonymous (nobody) Summary: How to use Range when Scale is negative Initial Comment: I think the spec could use an example that shows how to use the Range header when rewinding (Scale header is set to a negative value.) Or, instead of an example, some explanatory text could be added. The issue that I find a little bit confusing is how the server should specify the end of the range. The end of the range would be numerically smaller than the start of the range. I think the following illustrates a valid exchange: C->S: PLAY rtsp://server/a RTSP/1.0 Scale: -1 Range: npt=45- S->C: RTSP/1.0 200 OK Scale: -1 Range: npt=45-0 This is the type of example that I think would be nice to have in the spec. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513880&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 10:53:38 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513888 ] RTSP and NAT Bugs item #513888, was opened at 2002-02-06 10:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513888&group_id=23194 Category: General Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: RTSP and NAT Initial Comment: RTSP today is not that NAT friendly. Can something be done to fix that problem or shouldn't at least a note about it be written in the new spec? If you don't have a ALG can this problem be fixed? Known NAT issues with RTSP is and possible solutions based on NAT and SIP work: 1. Receiver ports are specifed in transport header. Needs to either be translated by ALG or client must find out the ports that will be used on the public side of the NAT. Mechanism for this has been proposed for SIP. 2. Transport header does not support explicit specification of RTCP ports. This seem to be required if any NAT port discovery will be possible to use. 3. Keep alive traffic needs to be sent over NAT translated ports when in pause to prevent binding timeout. Not an issue for RTCP port but also RTP ports needs to receive traffic. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513888&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Wed, 06 Feb 2002 10:57:01 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513891 ] Clarify use of Range in REDIRECT method Bugs item #513891, was opened at 2002-02-06 10:56 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&group_id=23194 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Nobody/Anonymous (nobody) Summary: Clarify use of Range in REDIRECT method Initial Comment: Section 10.10 says that the REDIRECT command can specify the Range header, to specify when the redirection should take place. The example shows a Range header that specificies an absolute time (UTC time.) Is it also possible to specify an NPT time for the REDIRECT command? How should a client interpret the end of the range when the Range header appears in the REDIRECT command? One way to interpret the end range time is to say that the client should connect back to the original server after that time. So, for example, if ServerA sends this command: REDIRECT rtsp://ServerB/foo RTSP/1.0 Range: npt=45-60 It could mean that the client should keep streaming from ServerA for time being, but when it reaches time NPT=45 in the presentation, then it should connect to ServerB and keep streaming from there for 15 seconds. After the time of the presentation reaches NPT=60, then the client will connect back to ServerA and continue streaming from there. Somehow, I feel that this might not be exactly what the authors of the spec had in mind. The spec needs to be clarified so that there is no ambiguity about how to interpret the Range header in this case. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513891&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 Mon Feb 11 20:21: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 UAA21420 for ; Mon, 11 Feb 2002 20:21:19 -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 UAA13249; Mon, 11 Feb 2002 20:20:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13211 for ; Mon, 11 Feb 2002 20:20:44 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21416 for ; Mon, 11 Feb 2002 20:20:42 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA07499; Mon, 11 Feb 2002 17:19:55 -0800 (PST) Message-ID: <3C686DB8.54056FD3@cisco.com> Date: Mon, 11 Feb 2002 20:19:52 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Ott CC: mmusic@ietf.org, mankin@isi.edu, csp@isi.edu, jdrosen@dynamicsoft.com Subject: Re: [MMUSIC] WG Last Call for Offer/Answer References: <3C5C1B02.73F44DC9@tzi.uni-bremen.de> 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 Some comments below: - p.2 says "The offer/answer model defined here is the mandatory baseline mechanism used by the Session Initiation Protocol (SIP) [3]". This requirement seems to belong in SIP, not offer/answer. - p. 3: Definition of Answerer says "An agent capable of sending and/or receiving media...". The ability to send/receive media should not be included here, i.e. strike "capable of sending and/or receiving media," - p. 3: Definition of Offerer: strike "capable of sending and/or receiving media," - p. 4: "The agent receiving the offer MAY generate an answer, or it MAY reject the offer.". At least in the unicast case, MUST you not always generate an answer which may either accept or reject the offer ? - p. 4: "However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or reject.". I'm not sure what this buys you since each side may generate an offer simultanously and hence you have to deal with the race anyway. (nits: "reject => rejected", and offers are either accepted or rejected, but always answered) p.4: "The offer MAY contain zero or more media streams..." A fairly empty statement (how do you not satisfy this ?). Section 5.1, first paragraph: You may want to elaborate on sendonly, recvonly, etc as a session attribute versus as a media attribute for specific media streams. p. 6: "However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer." Should add a sentence that the answerer MUST still send using the payload types from the offer. p. 8, last paragraph: Only recvonly and sendrecv streams are discussed. For completeness, sendonly streams should be mentioned as well. Also, consider moving this paragraph to right after the first paragraph on p.6, where similar issues are discussed. Section 5.2, first paragraph: I'd suggest writing this from the perspective of the offerer (like the rest of section 5), i.e. "answerer can only send (receive)" => "offerer can only receive (send)". p.9: Should state explicitly whether sendonly and sendrecv streams in an answer are allowed to contain any additional media formats or not. p. 10: "In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different." I agree with this and understand the difficulty in saying something more specific, however it still leaves open the question of how to negotiate fmtp parameters between an offer and an answer. Should there be a sentence saying that people defining fmtp parameters should define how they are negotiated in offer/answer ? p. 10: "The answerer MAY include a ptime" => "The answerer MAY include a non-zero ptime" p. 10: "When sending media, it SHOULD use a packetization interval equal to the value of the ptime attribute in the offer, if any was present.". Since ptime is a media stream attribute, this can be difficult to do if multiple media formats are specified. There should be a rounding rule to account for that (e.g. use closest non-zero ptime if you can't use the ptime specified). p. 11: "Similarly, the directionality information in the answer (sendonly, recvonly, or sendrecv) MUST equal that of the offer." It may be worth spelling it out more clearly what this means, since it differs from the unicast. p. 13: "Otherwise, the media description for the removed stream SHOULD be formatted identically to the corresponding stream in the previous SDP." Add ", except for the list of media formats." p. 13: "Removal of a media stream implies that media is no longer sent for that stream.". Add sentence "Furthermore, when RTP was used for the media stream, RTCP reports will no longer be sent or received." Section 8.3.1, first paragraph: "The offerer MUST NOT cease listening for media ..". In practice, it will not always be possible to satisfy this requirement, and hence it should rather be "SHOULD NOT". (Nit: "listening for" should be "receiving" - twice in the paragraph). Section 8.3.1, second paragraph: "The answerer MUST NOT cease listening for media on the old port until media arrives on the new port.". Same comments (also "listening for" => "receiving"). Section 8.3.2, first paragraph: "the mapping from a particular dynamic payload type number to a particular codec MUST NOT change". Needs to be clarified that it applies on a per media stream basis and not across the entire session. Section 8.4: Section seems to be unicast specific. Both heading and section text should reflect this. Section 9: Since the "capabilities" SDP is indistinguishable from an "offer/answer" SDP, we should make it clear, that this is determined by the context within which the SDP is provided (for example a SIP OPTIONS as opposed to INVITE). Section 9: "The transport component of the "m=" line indicates the preferred transport for that media type.". Not sure this is ideal. For example, if I support both RTP and SRTP, do I only indicate one of them (similar issue with T.38 UDP or TCP) ? Also, I have some strictly editorial nits which I'll send off-line. -- Flemming Joerg Ott wrote: > Folks, > > this is to announce Working Group Last Call on > > draft-ietf-mmusic-sdp-offer-answer-00.txt > > for Proposed Standard. Please note that this document is a > revision of draft-rosenberg-mmusic-offer-answer-00.txt. > > The WG Last Call is to expire in two weeks, on 16 Feb 2002. > > Please note that this document is referenced by SIP bis06 > and thus is crucial to the 3G work. So, please, review this > document quickly (it is not that long) and should you > have any comments, please submit them asap to the MMUSIC > mailing list and the authors. > > Thanks a lot, > Joerg > co-chair, MMUSIC > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 07:03: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 HAA08759 for ; Tue, 12 Feb 2002 07:03: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 HAA17215; Tue, 12 Feb 2002 07:03:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17186 for ; Tue, 12 Feb 2002 07:03:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08627; Tue, 12 Feb 2002 07:02:59 -0500 (EST) Message-Id: <200202121202.HAA08627@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, 12 Feb 2002 07:02:59 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.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-05.txt Pages : 45 Date : 11-Feb-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-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-new-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-new-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020211152440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-new-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-new-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020211152440.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 Feb 12 11: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 LAA16302 for ; Tue, 12 Feb 2002 11:02:11 -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 LAA29479; Tue, 12 Feb 2002 11:01:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA29361 for ; Tue, 12 Feb 2002 11:01:38 -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 LAA16241 for ; Tue, 12 Feb 2002 11:00:06 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1CG08H23917 for ; Tue, 12 Feb 2002 11:00:08 -0500 Message-Id: <200202121600.g1CG08H23917@chiron.nge.isi.edu> To: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt In-Reply-To: Your message of "Tue, 12 Feb 2002 07:02:59 EST." <200202121202.HAA08627@ietf.org> Date: Tue, 12 Feb 2002 11:00:08 -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 --> 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-05.txt > Pages : 45 > Date : 11-Feb-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-05.txt Changes in this version are: - Clarify that a=recvonly does NOT mean that you don't send RTCP, and similarly for sendonly and inactive. These only effect the RTP stream. - Fix ABNF to include a unicast-address element, allowing comedia to align with both this and RFC2327 - "s= " rather than "s=-" - Fix ABNF to reflect that s= is mandatory - Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 Any comments would be appreciated. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 18:39: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 SAA00786 for ; Tue, 12 Feb 2002 18:39: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 SAA20830; Tue, 12 Feb 2002 18:38:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA20803 for ; Tue, 12 Feb 2002 18:38:34 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00780 for ; Tue, 12 Feb 2002 18:38:31 -0500 (EST) Received: from RKUMAR-W2K.cisco.com (dhcp-128-107-142-103.cisco.com [128.107.142.103]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA23778; Tue, 12 Feb 2002 15:37:45 -0800 (PST) Message-Id: <4.3.2.7.2.20020212152724.020a1aa0@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Feb 2002 15:36:03 -0800 To: Colin Perkins From: Rajesh Kumar Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt Cc: mmusic@ietf.org In-Reply-To: <200202121600.g1CG08H23917@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 Colin, I suggest that acceptance of "s=-" when there is no meaningful session name be retained for backwards compatibility. After all, we're fixing an existing standard, and not creating a new one. Backward compatibility should be an important consideration. I believe "s=-" will satisfy the ABNF definition of the session name, and therefore there is no backward compatibility issue, right? Thanks, Rajesh At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: >Changes in this version are: >- Clarify that a=recvonly does NOT mean that you don't send RTCP, and > similarly for sendonly and inactive. These only effect the RTP stream. >- Fix ABNF to include a unicast-address element, allowing comedia to > align with both this and RFC2327 >- "s= " rather than "s=-" >- Fix ABNF to reflect that s= is mandatory >- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 > >Any comments would be appreciated. > >Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 19:27: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 TAA01504 for ; Tue, 12 Feb 2002 19:27:40 -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 TAA22386; Tue, 12 Feb 2002 19:27:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22353 for ; Tue, 12 Feb 2002 19:27:22 -0500 (EST) Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01500 for ; Tue, 12 Feb 2002 19:27:20 -0500 (EST) Received: from purple.nge.isi.edu (csp@localhost) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1D0R4x02930; Tue, 12 Feb 2002 19:27:05 -0500 Message-Id: <200202130027.g1D0R4x02930@purple.nge.isi.edu> To: Rajesh Kumar cc: mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt In-Reply-To: Your message of "Tue, 12 Feb 2002 15:36:03 PST." <4.3.2.7.2.20020212152724.020a1aa0@mira-sjc5-8.cisco.com> Date: Tue, 12 Feb 2002 19:27:04 -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 changed it to "s= " to match offer/answer, and because I was told that was what SIP clients expected. Colin --> Rajesh Kumar writes: >Colin, >I suggest that acceptance of "s=-" when there is no meaningful session name >be retained for backwards compatibility. After all, we're fixing an >existing standard, and not creating a new one. Backward compatibility >should be an important consideration. I believe "s=-" will satisfy the ABNF >definition of the session name, and therefore there is no backward >compatibility issue, right? > >Thanks, >Rajesh > >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: >>Changes in this version are: >>- Clarify that a=recvonly does NOT mean that you don't send RTCP, and >> similarly for sendonly and inactive. These only effect the RTP stream. >>- Fix ABNF to include a unicast-address element, allowing comedia to >> align with both this and RFC2327 >>- "s= " rather than "s=-" >>- Fix ABNF to reflect that s= is mandatory >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 >> >>Any comments would be appreciated. >> >>Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 19:44: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 TAA01736 for ; Tue, 12 Feb 2002 19:44:02 -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 TAA23028; Tue, 12 Feb 2002 19:41:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA22999 for ; Tue, 12 Feb 2002 19:41:11 -0500 (EST) Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01666 for ; Tue, 12 Feb 2002 19:41:01 -0500 (EST) Received: from purple.nge.isi.edu (csp@localhost) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1D0eSA03195; Tue, 12 Feb 2002 19:40:28 -0500 Message-Id: <200202130040.g1D0eSA03195@purple.nge.isi.edu> To: Rajesh Kumar cc: jswamina@cisco.com, smarch@cisco.com, joe Stone , axagrawa@cisco.com, flemming Andreasen , bfoster@cisco.com, mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt In-Reply-To: Your message of "Tue, 12 Feb 2002 16:33:03 PST." <4.3.2.7.2.20020212162905.020a1ba0@mira-sjc5-8.cisco.com> Date: Tue, 12 Feb 2002 19:40:28 -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 don't really care which is chosen, but it'd be good if we could have a single definition. RFC 2327 doesn't specify and offer/answer uses "s= ". I was following offer/answer, but maybe that conflicts with other use? Colin --> Rajesh Kumar writes: >Some h.248/MGCP applications use the old definition. I know of several that >are out there in the field. Therefore, I do not know if we can or should >alter it, short of defining a new protocol which this draft does not >purport to do. > >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So there >should be no backward compatibility problems. > >Rajesh > >At 07:27 PM 2/12/2002 -0500, you wrote: >>I changed it to "s= " to match offer/answer, and because I was told that >>was what SIP clients expected. >> >>Colin >> >> >> >>--> Rajesh Kumar writes: >> >Colin, >> >I suggest that acceptance of "s=-" when there is no meaningful session name >> >be retained for backwards compatibility. After all, we're fixing an >> >existing standard, and not creating a new one. Backward compatibility >> >should be an important consideration. I believe "s=-" will satisfy the ABNF >> >definition of the session name, and therefore there is no backward >> >compatibility issue, right? >> > >> >Thanks, >> >Rajesh >> > >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: >> >>Changes in this version are: >> >>- Clarify that a=recvonly does NOT mean that you don't send RTCP, and >> >> similarly for sendonly and inactive. These only effect the RTP stream. >> >>- Fix ABNF to include a unicast-address element, allowing comedia to >> >> align with both this and RFC2327 >> >>- "s= " rather than "s=-" >> >>- Fix ABNF to reflect that s= is mandatory >> >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 >> >> >> >>Any comments would be appreciated. >> >> >> >>Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 19:49: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 TAA01863 for ; Tue, 12 Feb 2002 19:49:47 -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 TAA23276; Tue, 12 Feb 2002 19:49:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23241 for ; Tue, 12 Feb 2002 19:49:24 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01860 for ; Tue, 12 Feb 2002 19:49:22 -0500 (EST) Received: from RKUMAR-W2K.cisco.com (dhcp-128-107-142-103.cisco.com [128.107.142.103]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id QAA19607; Tue, 12 Feb 2002 16:48:07 -0800 (PST) Message-Id: <4.3.2.7.2.20020212164517.0210ca88@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Feb 2002 16:46:27 -0800 To: Colin Perkins From: Rajesh Kumar Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt Cc: jswamina@cisco.com, smarch@cisco.com, joe Stone , axagrawa@cisco.com, flemming Andreasen , bfoster@cisco.com, mmusic@ietf.org In-Reply-To: <200202130040.g1D0eSA03195@purple.nge.isi.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_833386246==_.ALT" 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 --=====================_833386246==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote: >I don't really care which is chosen, but it'd be good if we could have a >single definition. RFC 2327 doesn't specify and offer/answer uses "s= ". >I was following offer/answer, but maybe that conflicts with other use? It does conflict, as I indicated. Since offer/answer is a draft, why not stick to s=- as stated in RFC 2327? What does the change buy for offer/answer?-Rajesh >Colin > > > >--> Rajesh Kumar writes: > >Some h.248/MGCP applications use the old definition. I know of several that > >are out there in the field. Therefore, I do not know if we can or should > >alter it, short of defining a new protocol which this draft does not > >purport to do. > > > >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So there > >should be no backward compatibility problems. > > > >Rajesh > > > >At 07:27 PM 2/12/2002 -0500, you wrote: > >>I changed it to "s= " to match offer/answer, and because I was told that > >>was what SIP clients expected. > >> > >>Colin > >> > >> > >> > >>--> Rajesh Kumar writes: > >> >Colin, > >> >I suggest that acceptance of "s=-" when there is no meaningful > session name > >> >be retained for backwards compatibility. After all, we're fixing an > >> >existing standard, and not creating a new one. Backward compatibility > >> >should be an important consideration. I believe "s=-" will satisfy > the ABNF > >> >definition of the session name, and therefore there is no backward > >> >compatibility issue, right? > >> > > >> >Thanks, > >> >Rajesh > >> > > >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: > >> >>Changes in this version are: > >> >>- Clarify that a=recvonly does NOT mean that you don't send RTCP, and > >> >> similarly for sendonly and inactive. These only effect the RTP > stream. > >> >>- Fix ABNF to include a unicast-address element, allowing comedia to > >> >> align with both this and RFC2327 > >> >>- "s= " rather than "s=-" > >> >>- Fix ABNF to reflect that s= is mandatory > >> >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 > >> >> > >> >>Any comments would be appreciated. > >> >> > >> >>Colin --=====================_833386246==_.ALT Content-Type: text/html; charset="us-ascii" At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote:
I don't really care which is chosen, but it'd be good if we could have a
single definition. RFC 2327 doesn't specify and offer/answer uses "s= ".
I was following offer/answer, but maybe that conflicts with other use?

It does conflict, as I indicated. Since offer/answer is a draft, why not stick to s=- as stated in RFC 2327? What does the change buy for offer/answer?-Rajesh


Colin



--> Rajesh Kumar writes:
>Some h.248/MGCP applications use the old definition. I know of several that
>are out there in the field. Therefore, I do not know if we can or should
>alter it, short of defining a new protocol which this draft does not
>purport to do.
>
>Anyway, I believe s=- is still canonical since '-' is ISO 10646. So there
>should be no backward compatibility problems.
>
>Rajesh
>
>At 07:27 PM 2/12/2002 -0500, you wrote:
>>I changed it to "s= " to match offer/answer, and because I was told that
>>was what SIP clients expected.
>>
>>Colin
>>
>>
>>
>>--> Rajesh Kumar writes:
>> >Colin,
>> >I suggest that acceptance of "s=-" when there is no meaningful session name
>> >be retained for backwards compatibility.  After all, we're fixing an
>> >existing standard, and not creating a new one. Backward compatibility
>> >should be an important consideration. I believe "s=-" will satisfy the ABNF
>> >definition of the session name, and therefore there is no backward
>> >compatibility issue, right?
>> >
>> >Thanks,
>> >Rajesh
>> >
>> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote:
>> >>Changes in this version are:
>> >>- Clarify that a=recvonly does NOT mean that you don't send RTCP, and
>> >>   similarly for sendonly and inactive.  These only effect the RTP stream.
>> >>- Fix ABNF to include a unicast-address element, allowing comedia to
>> >>   align with both this and RFC2327
>> >>- "s= " rather than "s=-"
>> >>- Fix ABNF to reflect that s= is mandatory
>> >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646
>> >>
>> >>Any comments would be appreciated.
>> >>
>> >>Colin
--=====================_833386246==_.ALT-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 19:59: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 TAA02059 for ; Tue, 12 Feb 2002 19:59:27 -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 TAA23511; Tue, 12 Feb 2002 19:58:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA23478 for ; Tue, 12 Feb 2002 19:58:24 -0500 (EST) Received: from nmh.informatik.uni-bremen.de (jo@nmh.informatik.uni-bremen.de [134.102.224.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02037 for ; Tue, 12 Feb 2002 19:58:22 -0500 (EST) Received: (from jo@localhost) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) id g1D0w3J00544; Wed, 13 Feb 2002 01:58:03 +0100 (MET) From: Joerg Ott Message-Id: <200202130058.g1D0w3J00544@nmh.informatik.uni-bremen.de> Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt To: rkumar@cisco.com (Rajesh Kumar) Date: Wed, 13 Feb 2002 01:58:03 +0100 (MET) Cc: csp@isi.edu (Colin Perkins), jswamina@cisco.com, smarch@cisco.com, joestone@cisco.com (joe Stone), axagrawa@cisco.com, fandreas@cisco.com (flemming Andreasen), bfoster@cisco.com, mmusic@ietf.org In-Reply-To: <4.3.2.7.2.20020212164517.0210ca88@mira-sjc5-8.cisco.com> from "Rajesh Kumar" at Feb 12, 2002 04:46:27 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Offer/answer follows the idea of referencing other documents. Quite a few implementations seem to use it this way. And offer/answer will be referenced by SIP. MEGACO has created its own "profile" of SDP anyway. And MEGACO does not become less SDP compliant than it currently is. Nor will existing implementations break. BTW: "s=-" is not stated in RFC2327. At least I can't find anything like that. Joerg > > --=====================_833386246==_.ALT > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote: > >I don't really care which is chosen, but it'd be good if we could have a > >single definition. RFC 2327 doesn't specify and offer/answer uses "s= ". > >I was following offer/answer, but maybe that conflicts with other use? > > It does conflict, as I indicated. Since offer/answer is a draft, why not > stick to s=- as stated in RFC 2327? What does the change buy for > offer/answer?-Rajesh > > > >Colin > > > > > > > >--> Rajesh Kumar writes: > > >Some h.248/MGCP applications use the old definition. I know of several that > > >are out there in the field. Therefore, I do not know if we can or should > > >alter it, short of defining a new protocol which this draft does not > > >purport to do. > > > > > >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So there > > >should be no backward compatibility problems. > > > > > >Rajesh > > > > > >At 07:27 PM 2/12/2002 -0500, you wrote: > > >>I changed it to "s= " to match offer/answer, and because I was told that > > >>was what SIP clients expected. > > >> > > >>Colin > > >> > > >> > > >> > > >>--> Rajesh Kumar writes: > > >> >Colin, > > >> >I suggest that acceptance of "s=-" when there is no meaningful > > session name > > >> >be retained for backwards compatibility. After all, we're fixing an > > >> >existing standard, and not creating a new one. Backward compatibility > > >> >should be an important consideration. I believe "s=-" will satisfy > > the ABNF > > >> >definition of the session name, and therefore there is no backward > > >> >compatibility issue, right? > > >> > > > >> >Thanks, > > >> >Rajesh > > >> > > > >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: > > >> >>Changes in this version are: > > >> >>- Clarify that a=recvonly does NOT mean that you don't send RTCP, and > > >> >> similarly for sendonly and inactive. These only effect the RTP > > stream. > > >> >>- Fix ABNF to include a unicast-address element, allowing comedia to > > >> >> align with both this and RFC2327 > > >> >>- "s= " rather than "s=-" > > >> >>- Fix ABNF to reflect that s= is mandatory > > >> >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 > > >> >> > > >> >>Any comments would be appreciated. > > >> >> > > >> >>Colin > > --=====================_833386246==_.ALT > Content-Type: text/html; charset="us-ascii" > > > At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote:
>
I don't really care which is chosen, but it'd > be good if we could have a
> single definition. RFC 2327 doesn't specify and offer/answer uses > "s= ".
> I was following offer/answer, but maybe that conflicts with other > use?

> It does conflict, as I indicated. Since offer/answer is a draft, why not > stick to s=- as stated in RFC 2327? What does the change buy for > offer/answer?-Rajesh
>
>
>
Colin
>
>
>
> --> Rajesh Kumar writes:
> >Some h.248/MGCP applications use the old definition. I know of > several that
> >are out there in the field. Therefore, I do not know if we can or > should
> >alter it, short of defining a new protocol which this draft does not >
> >purport to do.
> >
> >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So > there
> >should be no backward compatibility problems.
> >
> >Rajesh
> >
> >At 07:27 PM 2/12/2002 -0500, you wrote:
> >>I changed it to "s= " to match offer/answer, and > because I was told that
> >>was what SIP clients expected.
> >>
> >>Colin
> >>
> >>
> >>
> >>--> Rajesh Kumar writes:
> >> >Colin,
> >> >I suggest that acceptance of "s=-" when there is > no meaningful session name
> >> >be retained for backwards compatibility.  After all, > we're fixing an
> >> >existing standard, and not creating a new one. Backward > compatibility
> >> >should be an important consideration. I believe > "s=-" will satisfy the ABNF
> >> >definition of the session name, and therefore there is no > backward
> >> >compatibility issue, right?
> >> >
> >> >Thanks,
> >> >Rajesh
> >> >
> >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote:
> >> >>Changes in this version are:
> >> >>- Clarify that a=recvonly does NOT mean that you don't > send RTCP, and
> >> >>   similarly for sendonly and inactive.  > These only effect the RTP stream.
> >> >>- Fix ABNF to include a unicast-address element, > allowing comedia to
> >> >>   align with both this and RFC2327
> >> >>- "s= " rather than "s=-"
> >> >>- Fix ABNF to reflect that s= is mandatory
> >> >>- Clarify that s= is non-empty, and the contents SHOULD > be ISO 10646
> >> >>
> >> >>Any comments would be appreciated.
> >> >>
> >> >>Colin
> > --=====================_833386246==_.ALT-- > > > _______________________________________________ > 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 Feb 12 20:07: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 UAA02236 for ; Tue, 12 Feb 2002 20:07: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 UAA24302; Tue, 12 Feb 2002 20:07: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 UAA24265 for ; Tue, 12 Feb 2002 20:07:06 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02227 for ; Tue, 12 Feb 2002 20:07:04 -0500 (EST) Received: from RKUMAR-W2K.cisco.com (dhcp-128-107-142-103.cisco.com [128.107.142.103]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA02367; Tue, 12 Feb 2002 17:06:14 -0800 (PST) Message-Id: <4.3.2.7.2.20020212170241.0210bc00@mira-sjc5-8.cisco.com> X-Sender: rkumar@mira-sjc5-8.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Feb 2002 17:04:32 -0800 To: Joerg Ott From: Rajesh Kumar Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt Cc: mmusic@ietf.org In-Reply-To: <200202130058.g1D0w3J00544@nmh.informatik.uni-bremen.de> References: <4.3.2.7.2.20020212164517.0210ca88@mira-sjc5-8.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org I guess I was looking at username which RFC 2327 mentions can be dummied out to a "-". Notwithstanding, I do know several implementations that use a "s=-". The question is: Is "-" an illegal session name? That is all I need to know. Thanks, Rajesh At 01:58 AM 2/13/2002 +0100, Joerg Ott wrote: >Offer/answer follows the idea of referencing other documents. Quite a >few implementations seem to use it this way. And offer/answer will >be referenced by SIP. > >MEGACO has created its own "profile" of SDP anyway. And MEGACO does >not become less SDP compliant than it currently is. Nor will existing >implementations break. > >BTW: "s=-" is not stated in RFC2327. At least I can't find anything like >that. > >Joerg > > > > > --=====================_833386246==_.ALT > > Content-Type: text/plain; charset="us-ascii"; format=flowed > > > > At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote: > > >I don't really care which is chosen, but it'd be good if we could have a > > >single definition. RFC 2327 doesn't specify and offer/answer uses "s= ". > > >I was following offer/answer, but maybe that conflicts with other use? > > > > It does conflict, as I indicated. Since offer/answer is a draft, why not > > stick to s=- as stated in RFC 2327? What does the change buy for > > offer/answer?-Rajesh > > > > > > >Colin > > > > > > > > > > > >--> Rajesh Kumar writes: > > > >Some h.248/MGCP applications use the old definition. I know of > several that > > > >are out there in the field. Therefore, I do not know if we can or should > > > >alter it, short of defining a new protocol which this draft does not > > > >purport to do. > > > > > > > >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So > there > > > >should be no backward compatibility problems. > > > > > > > >Rajesh > > > > > > > >At 07:27 PM 2/12/2002 -0500, you wrote: > > > >>I changed it to "s= " to match offer/answer, and because I was told > that > > > >>was what SIP clients expected. > > > >> > > > >>Colin > > > >> > > > >> > > > >> > > > >>--> Rajesh Kumar writes: > > > >> >Colin, > > > >> >I suggest that acceptance of "s=-" when there is no meaningful > > > session name > > > >> >be retained for backwards compatibility. After all, we're fixing an > > > >> >existing standard, and not creating a new one. Backward compatibility > > > >> >should be an important consideration. I believe "s=-" will satisfy > > > the ABNF > > > >> >definition of the session name, and therefore there is no backward > > > >> >compatibility issue, right? > > > >> > > > > >> >Thanks, > > > >> >Rajesh > > > >> > > > > >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote: > > > >> >>Changes in this version are: > > > >> >>- Clarify that a=recvonly does NOT mean that you don't send > RTCP, and > > > >> >> similarly for sendonly and inactive. These only effect the RTP > > > stream. > > > >> >>- Fix ABNF to include a unicast-address element, allowing comedia to > > > >> >> align with both this and RFC2327 > > > >> >>- "s= " rather than "s=-" > > > >> >>- Fix ABNF to reflect that s= is mandatory > > > >> >>- Clarify that s= is non-empty, and the contents SHOULD be ISO 10646 > > > >> >> > > > >> >>Any comments would be appreciated. > > > >> >> > > > >> >>Colin > > > > --=====================_833386246==_.ALT > > Content-Type: text/html; charset="us-ascii" > > > > > > At 07:40 PM 2/12/2002 -0500, Colin Perkins wrote:
> >
I don't really care which is chosen, but it'd > > be good if we could have a
> > single definition. RFC 2327 doesn't specify and offer/answer uses > > "s= ".
> > I was following offer/answer, but maybe that conflicts with other > > use?

> > It does conflict, as I indicated. Since offer/answer is a draft, why not > > stick to s=- as stated in RFC 2327? What does the change buy for > > offer/answer?-Rajesh
> >
> >
> >
Colin
> >
> >
> >
> > --> Rajesh Kumar writes:
> > >Some h.248/MGCP applications use the old definition. I know of > > several that
> > >are out there in the field. Therefore, I do not know if we can or > > should
> > >alter it, short of defining a new protocol which this draft does not > >
> > >purport to do.
> > >
> > >Anyway, I believe s=- is still canonical since '-' is ISO 10646. So > > there
> > >should be no backward compatibility problems.
> > >
> > >Rajesh
> > >
> > >At 07:27 PM 2/12/2002 -0500, you wrote:
> > >>I changed it to "s= " to match offer/answer, and > > because I was told that
> > >>was what SIP clients expected.
> > >>
> > >>Colin
> > >>
> > >>
> > >>
> > >>--> Rajesh Kumar writes:
> > >> >Colin,
> > >> >I suggest that acceptance of "s=-" when there is > > no meaningful session name
> > >> >be retained for backwards compatibility.  After all, > > we're fixing an
> > >> >existing standard, and not creating a new one. Backward > > compatibility
> > >> >should be an important consideration. I believe > > "s=-" will satisfy the ABNF
> > >> >definition of the session name, and therefore there is no > > backward
> > >> >compatibility issue, right?
> > >> >
> > >> >Thanks,
> > >> >Rajesh
> > >> >
> > >> >At 11:00 AM 2/12/2002 -0500, Colin Perkins wrote:
> > >> >>Changes in this version are:
> > >> >>- Clarify that a=recvonly does NOT mean that you don't > > send RTCP, and
> > >> >>   similarly for sendonly and inactive.  > > These only effect the RTP stream.
> > >> >>- Fix ABNF to include a unicast-address element, > > allowing comedia to
> > >> >>   align with both this and RFC2327
> > >> >>- "s= " rather than "s=-"
> > >> >>- Fix ABNF to reflect that s= is mandatory
> > >> >>- Clarify that s= is non-empty, and the contents SHOULD > > be ISO 10646
> > >> >>
> > >> >>Any comments would be appreciated.
> > >> >>
> > >> >>Colin
> > > > --=====================_833386246==_.ALT-- > > > > > > _______________________________________________ > > 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 Tue Feb 12 21:19: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 VAA03773 for ; Tue, 12 Feb 2002 21:19:49 -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 VAA26864; Tue, 12 Feb 2002 21:19: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 VAA26833 for ; Tue, 12 Feb 2002 21:19:19 -0500 (EST) Received: from purple.nge.isi.edu (reserved.east.isi.edu [65.114.168.32]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03767 for ; Tue, 12 Feb 2002 21:19:16 -0500 (EST) Received: from purple.nge.isi.edu (csp@localhost) by purple.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1D2J7K04007; Tue, 12 Feb 2002 21:19:07 -0500 Message-Id: <200202130219.g1D2J7K04007@purple.nge.isi.edu> To: Rajesh Kumar cc: Joerg Ott , mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt In-Reply-To: Your message of "Tue, 12 Feb 2002 17:04:32 PST." <4.3.2.7.2.20020212170241.0210bc00@mira-sjc5-8.cisco.com> Date: Tue, 12 Feb 2002 21:19:07 -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 --> Rajesh Kumar writes: >I guess I was looking at username which RFC 2327 mentions can be dummied >out to a "-". > >Notwithstanding, I do know several implementations that use a "s=-". The >question is: Is "-" an illegal session name? That is all I need to know. No, it's not illegal. The "s= " is just a recommendation if there's nothing better to use; you can use whatever you like for a session name. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 22:49:26 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 WAA07031 for ; Tue, 12 Feb 2002 22:49:25 -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 WAA00322; Tue, 12 Feb 2002 22:49: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 WAA00292 for ; Tue, 12 Feb 2002 22:49:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07028 for ; Tue, 12 Feb 2002 22:49:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1D3n26Y028946; Tue, 12 Feb 2002 22:49:02 -0500 (EST) Message-ID: <3C69E1FC.934E3D61@dynamicsoft.com> Date: Tue, 12 Feb 2002 22:48:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Colin Perkins CC: Rajesh Kumar , Joerg Ott , mmusic@ietf.org Subject: Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-new-05.txt References: <200202130219.g1D2J7K04007@purple.nge.isi.edu> 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 I don't understand the problem. A valid SDP implementation should accept anything. Whether its " " or "-" is irrelevant. As Colin says, these are just suggestions in any case. -Jonathan R. Colin Perkins wrote: > > --> Rajesh Kumar writes: > >I guess I was looking at username which RFC 2327 mentions can be > dummied > >out to a "-". > > > >Notwithstanding, I do know several implementations that use a "s=-". > The > >question is: Is "-" an illegal session name? That is all I need to > know. > > No, it's not illegal. The "s= " is just a recommendation if there's > nothing > better to use; you can use whatever you like for a session name. > > Colin > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 12 23:07: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 XAA07264 for ; Tue, 12 Feb 2002 23:07: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 XAA01084; Tue, 12 Feb 2002 23:07:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA01051 for ; Tue, 12 Feb 2002 23:07:03 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07260 for ; Tue, 12 Feb 2002 23:07:00 -0500 (EST) DATE: 13 Feb 2002 04:07:01 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 13 Feb 2002 04:07:02 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA01052 Subject: [MMUSIC] Using payload types not specified in answer in offer/answer 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 It is unclear from the specification whether answerer is allowed to send media with payload types not specified in the response to sendonly or sendrecv offer. It clearly states that the offerer should be prepared to receive those payload types before the answer arrives, but is it safe to assume that those payload types will not be used if they are not specified in the answer once the answer was received?___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 11:04: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 LAA09068 for ; Wed, 13 Feb 2002 11:04:37 -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 LAA12941; Wed, 13 Feb 2002 11:04:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12899 for ; Wed, 13 Feb 2002 11:04:09 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09037 for ; Wed, 13 Feb 2002 11:04:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DG416Y029370; Wed, 13 Feb 2002 11:04:02 -0500 (EST) Message-ID: <3C6A8E42.82690028@dynamicsoft.com> Date: Wed, 13 Feb 2002 11:03:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > > It is unclear from the specification whether answerer is allowed to send > media with payload types not specified in the response to sendonly or > sendrecv offer. This doesn't make sense to me. If the offer is sendonly, the answer is recvonly, so the answerer cannot send media. In the case of sendrecv, it should only be sending with codecs in its answer. This is in the document: It {\MUST} be prepared to send and receive media for any sendrecv streams in the answer, and {\MAY} send media immediately. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 12:27: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 MAA14628 for ; Wed, 13 Feb 2002 12:27:37 -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 MAA18427; Wed, 13 Feb 2002 12:25:51 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18401 for ; Wed, 13 Feb 2002 12:25:50 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14555 for ; Wed, 13 Feb 2002 12:25:46 -0500 (EST) DATE: 13 Feb 2002 17:25:49 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 13 Feb 2002 17:25:49 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA18402 Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 My mistake. What I wanted to say was if the offer was recvonly or sendrecv. For example if the offer is: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 110 a=rtpmap:0 PCMU/8000 a=rtpmap:110 telephone-events a=recvonly And if the answer is v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 47920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly Is the answerer allowed to send AVT tones with a RTP payload type 110? ___________________________________ Roman Shpount ------ Original message ------ >From: Jonathan Rosenberg >Subject: Re: Using payload types not specified in answer in offer/answer >Date: 13 Feb 02, 04:03 PM >To: Roman Shpount >Cc: mmusic@ietf.org Roman Shpount wrote: > > It is unclear from the specification whether answerer is allowed to send > media with payload types not specified in the response to sendonly or > sendrecv offer. This doesn't make sense to me. If the offer is sendonly, the answer is recvonly, so the answerer cannot send media. In the case of sendrecv, it should only be sending with codecs in its answer. This is in the document: It {\MUST} be prepared to send and receive media for any sendrecv streams in the answer, and {\MAY} send media immediately. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 13:28: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 NAA16282 for ; Wed, 13 Feb 2002 13:28:13 -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 NAA21310; Wed, 13 Feb 2002 13:24:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21279 for ; Wed, 13 Feb 2002 13:24:15 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16188 for ; Wed, 13 Feb 2002 13:24:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DIO96Y029607; Wed, 13 Feb 2002 13:24:09 -0500 (EST) Message-ID: <3C6AAF1A.DE1D4A11@dynamicsoft.com> Date: Wed, 13 Feb 2002 13:23:22 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > > My mistake. What I wanted to say was if the offer was recvonly or > sendrecv. For example if the offer is: > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > s= > c=IN IP4 host.anywhere.com > t=0 0 > m=audio 49170 RTP/AVP 0 110 > a=rtpmap:0 PCMU/8000 > a=rtpmap:110 telephone-events > a=recvonly > > And if the answer is > > v=0 > o=bob 2890844730 2890844730 IN IP4 host.example.com > s= > c=IN IP4 host.example.com > t=0 0 > m=audio 47920 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=sendonly > > Is the answerer allowed to send AVT tones with a RTP payload type 110? No. But, if it wants to, why would it delete it from the anwer? Just put it in. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 13:56: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 NAA17299 for ; Wed, 13 Feb 2002 13:56:19 -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 NAA23085; Wed, 13 Feb 2002 13:52:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23049 for ; Wed, 13 Feb 2002 13:52:42 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17183 for ; Wed, 13 Feb 2002 13:52:39 -0500 (EST) DATE: 13 Feb 2002 18:52:40 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 13 Feb 2002 18:52:40 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA23050 Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > > My mistake. What I wanted to say was if the offer was recvonly or > sendrecv. For example if the offer is: > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > s= > c=IN IP4 host.anywhere.com > t=0 0 > m=audio 49170 RTP/AVP 0 110 > a=rtpmap:0 PCMU/8000 > a=rtpmap:110 telephone-events > a=recvonly > > And if the answer is > > v=0 > o=bob 2890844730 2890844730 IN IP4 host.example.com > s= > c=IN IP4 host.example.com > t=0 0 > m=audio 47920 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > a=sendonly > > Is the answerer allowed to send AVT tones with a RTP payload type 110? Jonathan D. Rosenberg wrote: >No. > >But, if it wants to, why would it delete it from the anwer? Just put it >in. Is it stated somewhere in the offer/answer? Again, it probably makes little sence for recvonly, but it is quite common for sendrecv as well. So if we modify above example for the sendrecv scenario. The offer would be: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 110 a=rtpmap:0 PCMU/8000 a=rtpmap:110 telephone-events And if the answer would be: v=0 o=bob 2890844730 2890844730 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 47920 RTP/AVP 0 a=rtpmap:0 PCMU/8000 Would any party on the call be allowed to use avt tones? If it does or does not, where is it specified? ___________________________________ Roman Shpount _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 14:42: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 OAA18739 for ; Wed, 13 Feb 2002 14:42:02 -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 OAA26908; Wed, 13 Feb 2002 14:41:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26874 for ; Wed, 13 Feb 2002 14:41:36 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18731 for ; Wed, 13 Feb 2002 14:41:32 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA27738; Wed, 13 Feb 2002 11:40:48 -0800 (PST) Message-ID: <3C6AC138.6E405FC@cisco.com> Date: Wed, 13 Feb 2002 14:40:40 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6AAF1A.DE1D4A11@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Roman Shpount wrote: > > > > My mistake. What I wanted to say was if the offer was recvonly or > > sendrecv. For example if the offer is: > > > > v=0 > > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > > s= > > c=IN IP4 host.anywhere.com > > t=0 0 > > m=audio 49170 RTP/AVP 0 110 > > a=rtpmap:0 PCMU/8000 > > a=rtpmap:110 telephone-events > > a=recvonly > > > > And if the answer is > > > > v=0 > > o=bob 2890844730 2890844730 IN IP4 host.example.com > > s= > > c=IN IP4 host.example.com > > t=0 0 > > m=audio 47920 RTP/AVP 0 > > a=rtpmap:0 PCMU/8000 > > a=sendonly > > > > Is the answerer allowed to send AVT tones with a RTP payload type 110? > > No. > No ? I believe the answer is yes. Haven't we always said, that the SDP indicates the set of media formats I can receive (assuming proper direction attributes), and I want to change that, I need to send a new SDP ? Where in offer/answer is this restriction described ? Also, if it you still mean "no", then I don't understand why you want to allow the answer to contain media formats not specified in the offer ? If asymmetry is allowed in one direction, it should be allowed in both. > > But, if it wants to, why would it delete it from the anwer? Same reason as the answerer might want to add a media format not present in the offer: asymmetry (e.g. I can send RFC 2833 to you, but I can't receive it). -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 15:15: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 PAA19585 for ; Wed, 13 Feb 2002 15:15:53 -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 PAA28513; Wed, 13 Feb 2002 15:12: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 PAA28478 for ; Wed, 13 Feb 2002 15:12:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19530 for ; Wed, 13 Feb 2002 15:12:14 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1DKCD6Y029747; Wed, 13 Feb 2002 15:12:13 -0500 (EST) Message-ID: <3C6AC86C.7D28708@dynamicsoft.com> Date: Wed, 13 Feb 2002 15:11:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6AC138.6E405FC@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > > > Is the answerer allowed to send AVT tones with a RTP payload type > 110? > > > > No. > > > > No ? I believe the answer is yes. Haven't we always said, that the SDP > indicates the set of media formats I can receive (assuming proper > direction > attributes), and I want to change that, I need to send a new SDP ? It indicates what you can receive for recvonly, indicates what you send for sendonly, and indicates what you will both send and receive for sendrecv. I thought you had argued strongly for that view at IETF 52... > > Where in offer/answer is this restriction described ? Also, if it you > still > mean "no", then I don't understand why you want to allow the answer to > contain media formats not specified in the offer ? If asymmetry is > allowed > in one direction, it should be allowed in both. In the case of sendrecv, subsetting is the only thing that makes sense. If A indicates in an offer that it can send and receive with codecs 1,2,3, and B indicates in its answer that it can send and receive with 2,3,4, the presence of 4 is useless. B can't send with it, since it doesn't know whether A can receive it. Now, consider the case once more of sendrecv, where A sends 1,2,3 in the offer, and B sends 1,2 in the answer. Can B send with codec 3? No, it can't. It can't because A can't send with it, and thus the codec would effectively be unidirectional. This is a birdirectional stream. So, in the case of sendrecv, B needs to be prepared to send and receive with the codecs in the answer, and this is what the text says: -- Once the answerer has sent the answer, it {\MUST} be prepared to receive media for any recvonly streams described by that answer. It {\MUST} be prepared to send and receive media for any sendrecv streams in the answer, and {\MAY} send media immediately. -- Now, in the case of a recvonly offer, A could indicate the ability to receive 1,2, and 3. In the answer, lets say B returns 1,2 as sendonly. But, then it sends using 3 anyway. If the answerer does not go with whats in the answer, the answer provides zero information. The point of the answer in this case is to help the offerer restrict the set of codecs it needs to be prepared to receive. I do admit that I find no text at the moment which says that the answerer in a sendonly answer should send only with the codecs in the answer. However, that has been my interprtation. Let me ask the converse - what is gained by having the answerer be able to send with things not in the answer? Why not just include them in the answer? > > > > > But, if it wants to, why would it delete it from the anwer? > > Same reason as the answerer might want to add a media format not present > in > the offer: asymmetry (e.g. I can send RFC 2833 to you, but I can't > receive it). Remember, we only support asymmetric codecs in asymmetric stream types. In the case you describe, you are talking about a recvonly offer and a sendonly answer. The spec says that the offer lists the codecs the offerer can receive. If its not there, what is gained by adding it in the answer? The answerer can't send it anyway, since it doesn't know if the offerer supports it? We did previously allow addition of recvonly codecs by the answerer in a sendrecv stream, but agreed at IETF 52 to remove this hack in favor of FID, which is the proper way to support such things. I recall you argued in favor of that, even. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 15:40: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 PAA20140 for ; Wed, 13 Feb 2002 15:40:36 -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 PAA00033; Wed, 13 Feb 2002 15:36:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA29993 for ; Wed, 13 Feb 2002 15:36:41 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20077 for ; Wed, 13 Feb 2002 15:36:37 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA16627; Wed, 13 Feb 2002 12:35:58 -0800 (PST) Message-ID: <3C6ACE25.1815FACD@cisco.com> Date: Wed, 13 Feb 2002 15:35:49 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6AC138.6E405FC@cisco.com> <3C6AC86C.7D28708@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Flemming Andreasen wrote: > > > > > > Is the answerer allowed to send AVT tones with a RTP payload type > > 110? > > > > > > No. > > > > > > > No ? I believe the answer is yes. Haven't we always said, that the SDP > > indicates the set of media formats I can receive (assuming proper > > direction > > attributes), and I want to change that, I need to send a new SDP ? > > It indicates what you can receive for recvonly, indicates what you send > for sendonly, and indicates what you will both send and receive for > sendrecv. I thought you had argued strongly for that view at IETF 52... > Yes - that's what I meant. > > > > > Where in offer/answer is this restriction described ? Also, if it you > > still > > mean "no", then I don't understand why you want to allow the answer to > > contain media formats not specified in the offer ? If asymmetry is > > allowed > > in one direction, it should be allowed in both. > > In the case of sendrecv, subsetting is the only thing that makes sense. > If A indicates in an offer that it can send and receive with codecs > 1,2,3, and B indicates in its answer that it can send and receive with > 2,3,4, the presence of 4 is useless. B can't send with it, since it > doesn't know whether A can receive it. Correct, but A can send with it. > > > Now, consider the case once more of sendrecv, where A sends 1,2,3 in the > offer, and B sends 1,2 in the answer. Can B send with codec 3? No, it > can't. It can't because A can't send with it, and thus the codec would > effectively be unidirectional. I don't buy that argument since you could equally well have A sending with 1 and B sending with 2. > This is a birdirectional stream. So, in > the case of sendrecv, B needs to be prepared to send and receive with > the codecs in the answer, and this is what the text says: > > -- > Once the answerer has sent the answer, it {\MUST} be prepared to > receive media for any recvonly streams described by that answer. It > {\MUST} be prepared to send and receive media for any sendrecv streams > in the answer, and {\MAY} send media immediately. > -- > If the above was the intended implication, then it's not entirely clear. > > Now, in the case of a recvonly offer, A could indicate the ability to > receive 1,2, and 3. In the answer, lets say B returns 1,2 as sendonly. > But, then it sends using 3 anyway. If the answerer does not go with > whats in the answer, the answer provides zero information. The point of > the answer in this case is to help the offerer restrict the set of > codecs it needs to be prepared to receive. I thought it was so offerer can figure out what he can actually send with (ignoring some of the unidirectional stream cases for a momemt). > I do admit that I find no > text at the moment which says that the answerer in a sendonly answer > should send only with the codecs in the answer. However, that has been > my interprtation. I have always understood, that once I hand out an SDP indicating the ability to receive codec 1,2, and 3, then I have to be able to receive those codecs until I send out another SDP. Of course you can say, that this is because SDP never defined the negotiation that offer/answer does, but this seems to introduce an unnecesary deviation from "normal" SDP usage. > > > Let me ask the converse - what is gained by having the answerer be able > to send with things not in the answer? Why not just include them in the > answer? It could for example be that I can send RFC 2833 but not receive it. Admittedly, SDP is not really good at expressing such unidirectional constraints, and we probably shouldn't get hung up on it (however I thought this was one of your concerns). My real concern here is that it seems to deviate from current SDP behavior. > > > > > > > > > > But, if it wants to, why would it delete it from the anwer? > > > > Same reason as the answerer might want to add a media format not present > > in > > the offer: asymmetry (e.g. I can send RFC 2833 to you, but I can't > > receive it). > > Remember, we only support asymmetric codecs in asymmetric stream types. We do ? If I offer 2 or more codecs and you answer with two or more codecs, then we can have asymmetric codec usage. > > In the case you describe, you are talking about a recvonly offer and a > sendonly answer. The spec says that the offer lists the codecs the > offerer can receive. If its not there, what is gained by adding it in > the answer? The answerer can't send it anyway, since it doesn't know if > the offerer supports it? > However, I thought it would apply to bidirectional streams as well. For example, if RFC 2833 is not offered , but the answerer is able to accept it, he may want to indicate so in the answer (and vice versa). > > We did previously allow addition of recvonly codecs by the answerer in a > sendrecv stream, but agreed at IETF 52 to remove this hack in favor of > FID, which is the proper way to support such things. I recall you argued > in favor of that, even. I still do, however that doesn't mean you can't add a sendrecv codec to a sendrecv stream, even though you may only be able to send or receive with it. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 13 15:48: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 PAA20313 for ; Wed, 13 Feb 2002 15:48:49 -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 PAA00661; Wed, 13 Feb 2002 15:48: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 PAA00626 for ; Wed, 13 Feb 2002 15:48:17 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20308 for ; Wed, 13 Feb 2002 15:48:15 -0500 (EST) DATE: 13 Feb 2002 20:48:16 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 13 Feb 2002 20:48:16 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Cc: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA00627 Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Jonathan D. Rosenberg wrote: > Let me ask the converse - what is gained by having the answerer be able > to send with things not in the answer? Why not just include them in the > answer? This is primarily a question of interpretation. I know at least one gateway implementation which is capable of sending, but not receiving avt tones. So this gateway replies to a sendrecv offer, which contains avt tones and G.711, with an answer that contains only G.711, but sends out avt tones anyway. I am looking for the language that states whether this behavior is legal or not. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 01:08: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 BAA04059 for ; Thu, 14 Feb 2002 01:08:28 -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 BAA04525; Thu, 14 Feb 2002 01:07:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA04426 for ; Thu, 14 Feb 2002 01:07:55 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04054 for ; Thu, 14 Feb 2002 01:07:53 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1E6846Y000848; Thu, 14 Feb 2002 01:08:04 -0500 (EST) Message-ID: <3C6B5415.DCD401F@dynamicsoft.com> Date: Thu, 14 Feb 2002 01:07:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Joerg Ott , mmusic@ietf.org, mankin@isi.edu, csp@isi.edu Subject: Re: [MMUSIC] WG Last Call for Offer/Answer References: <3C686DB8.54056FD3@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming, Thanks for your comments. Responses inline. Flemming Andreasen wrote: > > Some comments below: > > - p.2 says "The offer/answer model defined here is the mandatory > baseline mechanism used by the Session > Initiation Protocol (SIP) [3]". This requirement seems to belong in SIP, > not offer/answer. Its not a normative statement; it merely provides a context for the reader of this document. I think its valuable to note that this mechanism is what SIP uses. > > - p. 3: Definition of Answerer says "An agent capable of sending > and/or receiving media...". The ability to > send/receive media should not be included here, i.e. strike "capable of > sending and/or receiving media," I got a similar comment in private email. I removed the text. > > - p. 3: Definition of Offerer: strike "capable of sending and/or > receiving media," Done. > > - p. 4: "The agent receiving the offer MAY generate an answer, or it > MAY reject the offer.". At least in the unicast case, MUST you not > always generate an answer which may either accept or reject the offer ? No. You can reject the offer outright. In the case of SIP, that would mean sending a 488. There is no answer in the 488. > > - p. 4: "However, it MUST NOT generate a new offer if it has received > an offer which it has not yet answered or reject.". I'm not sure what > this buys you since each side may generate an offer simultanously and > hence you have to deal with the race anyway. (nits: "reject => > rejected", and offers are either accepted or rejected, but always > answered) The nit has been fixed already. I have also already added text saying that the higher layer protocol needs to provide a away to resolve the glare condition of both sending offers simultaneously. It is always best to prevent those kinds of glare conditions from happening, since they do take time to resolve (can be seconds, at least, for the sip glare resolution mechanisms). Thus, the text about not sending an offer when you have one outstanding is a good one, I think. > > p.4: "The offer MAY contain zero or more media streams..." A fairly > empty statement (how do you not satisfy this ?). Good point. The sentence is needed to preface the following sentence, which define a meaning for zero media streams. So, I've reworded the first sentence to be non-normative. The first two sentences now read: The offer will contain zero or more media streams (each media stream is described by an m line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. > > Section 5.1, first paragraph: You may want to elaborate on sendonly, > recvonly, etc as a session attribute versus as a media attribute for > specific media streams. Excellent point. The paragraph now reads: If the offerer wishes to only send media on a stream to its peer, it {\MUST} mark the stream as sendonly with the a=sendonly attribute. We refer to a stream as being marked with a certain direction if a direction attribute was present as either a media stream attribute or a session attribute. If the offerer wishes to only receive media from its peer, it {\MUST} mark the stream as recvonly. > > p. 6: "However, for sendonly and sendrecv streams, the answer might > indicate different payload type numbers for the same codecs, in which > case, the offerer MUST send with the payload type numbers from the > answer." Should add a sentence that the answerer MUST still send using > the payload types from the offer. Yes, thats a good point. That belongs farther down, in the section on answerer behavior. The bottom of that paragraph now reads: It {\SHOULD} send media using a banwdith no higher than the value of the bandwidth attribute in the offer, if any was present. The answerer {\SHOULD} send using the most preferred codec in the offer supported by the answerer. In the case of RTP, it {\MUST} use the payload type numbers from the offer, even if they differ from those in the answer. > > p. 8, last paragraph: Only recvonly and sendrecv streams are > discussed. For completeness, sendonly streams should be mentioned as > well. Also, consider moving this paragraph to right after the first > paragraph on p.6, where similar issues are discussed. Actually its page 7. I added a sentence on sendonly. I like the paragraph where it is, since it descsribes the processing that the offerer follows after sending the offer, but before the answer. The first paragraph on p. 6 describes the general meaning of the direction attributes and m lines. > > Section 5.2, first paragraph: I'd suggest writing this from the > perspective of the offerer (like the rest of section 5), i.e. "answerer > can only send (receive)" => "offerer can only receive (send)". Actually, I've been trying to get my arms around exactly what the meaning is for multicast. The text thats there now, or your text, are both wrong I think; they take a unicast view of the SDP. Really, for multicast, it should be like the SAP usage. If a stream is recvonly, then all participants, including the offerer and answerer, will only receive on it. This is already reflected in how the answer is generated (the directionalities are not flipped). So, I have reworded this section to read: If a session description contains a multicast media stream which is listed as receive (send) only, it means that the participants, including the offerer and answerer, can only receive (send) on that stream. This differs from the unicast view, where the directionality refers to the flow of media between offerer and answerer. > > p.9: Should state explicitly whether sendonly and sendrecv streams in > an answer are allowed to contain any additional media formats or not. We're discussing that one on the list... I've logged it in bugzilla as an open issue. > > p. 10: "In that case, the answer MAY contain fmtp parameters, and > those MAY have the same values as those in the offer, or they MAY be > different." I agree with this and understand the difficulty in saying > something more specific, however it still leaves open the question of > how to negotiate fmtp parameters between an offer and an answer. Should > there be a sentence saying that people defining fmtp parameters should > define how they are negotiated in offer/answer ? I was debating that. I didn't put it in because I thought it was too burdensome for drafts that define them, but its probably a good idea. I'll add it. Speak now if you have a problem with that.... Here is the sentence I tacked on here: SDP extensions that define new parameters {\SHOULD} specify the proper interpretation in offer/answer. we can debate whether this is SHOULD or should; a similar debate is going on in bis about whether such statements even belong in bis. However, I think normative makes sense, and unlike bis, where we have another document which defines rules for extensions (draft-ietf-sip-guidelines), there isn't anywhere else to put it. > > p. 10: "The answerer MAY include a ptime" => "The answerer MAY > include a non-zero ptime" I didn't include that restriction for the offer, and you had no comment on it there. Do I interpret this to mean you want this restriction only for the answer, or do you really want it for both? It had never even occurred to me to use a zero ptime, I don't even know what that would mean.... > > p. 10: "When sending media, it SHOULD use a packetization interval > equal to the value of the ptime attribute in the offer, if any was > present.". Since ptime is a media stream attribute, this can be > difficult to do if multiple media formats are specified. There should be > a rounding rule to account for that (e.g. use closest non-zero ptime if > you can't use the ptime specified). This is really a general SDP issue, not specific to O/A. Do we want to discuss it here? Probably sdp-new should clarify this. > > p. 11: "Similarly, the directionality information in the answer > (sendonly, recvonly, or sendrecv) MUST equal that of the offer." It may > be worth spelling it out more clearly what this means, since it differs > from the unicast. I mention it in the text on constructing the offer, see above response. > > p. 13: "Otherwise, the media description for the removed stream > SHOULD be formatted identically to the corresponding stream in the > previous SDP." Add ", except for the list of media formats." I rewrote this altogether, since the stream really isn't formatted at all identically to the corresponding stream in the previous SDP. It now reads: A stream that is offered with a port of zero {\MUST} be marked with port zero in the answer. Like the offer, the answer {\MAY} omit all attributes present previously, and {\MAY} list just a single media format from amongst those in the offer. > > p. 13: "Removal of a media stream implies that media is no longer > sent for that stream.". Add sentence "Furthermore, when RTP was used for > the media stream, RTCP reports will no longer be sent or received." Added: In the case of RTP, RTCP transmission also ceases. > > Section 8.3.1, first paragraph: "The offerer MUST NOT cease listening > for media ..". In practice, it will not always be possible to satisfy > this requirement, and hence it should rather be "SHOULD NOT". (Nit: > "listening for" should be "receiving" - twice in the paragraph). On MUST NOT -> SHOULD NOT; OK, I made that change. I also added a note that said if you don't, there could be media loss during the transition. I don;'t want to encourage people to break the SHOULD. Regarding listening for -> receiving, I disagree. Listening is not the same as receiving; you can be listening, but receive nothing. Listening is the ability to receive. In this case, it truly is the ability to receive, not the actual act of receiving which is mandated. > > Section 8.3.1, second paragraph: "The answerer MUST NOT cease > listening for media on the old port until media arrives on the new > port.". Same comments (also "listening for" => "receiving"). Same as above. > > Section 8.3.2, first paragraph: "the mapping from a particular > dynamic payload type number to a particular codec MUST NOT change". > Needs to be clarified that it applies on a per media stream basis and > not across the entire session. OK. I clarified. > > Section 8.4: Section seems to be unicast specific. Both heading and > section text should reflect this. I changed the section heading to "putting a unicast stream on hold". I see no need to repeat that within the body text. > > Section 9: Since the "capabilities" SDP is indistinguishable from an > "offer/answer" SDP, we should make it clear, that this is determined by > the context within which the SDP is provided (for example a SIP OPTIONS > as opposed to INVITE). Good point. Added: Since SDP has no way to indicate that the message is for the purpose of capability indication, this is determined from the context of the higher layer protocol. > > Section 9: "The transport component of the "m=" line indicates the > preferred transport for that media type.". Not sure this is ideal. For > example, if I support both RTP and SRTP, do I only indicate one of them > (similar issue with T.38 UDP or TCP) ? Yes. Its not really preferred, its "the one". If you want to indicate support for both SRTP and RTP, you would pick one in the offer, include simcaps indicating the other. Similar in the answer. THe offerer could then send an updated offer switching to SRTP. This is discussed in the unify draft. > > Also, I have some strictly editorial nits which I'll send off-line. OK, thanks. I appreciate your comments. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 03:15:31 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 DAA13118 for ; Thu, 14 Feb 2002 03:15:31 -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 DAA14848; Thu, 14 Feb 2002 03:07: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 DAA14817 for ; Thu, 14 Feb 2002 03:07:27 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13064 for ; Thu, 14 Feb 2002 03:07:24 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1E87Z6Y001027; Thu, 14 Feb 2002 03:07:36 -0500 (EST) Message-ID: <3C6B7019.8EB4FCDE@dynamicsoft.com> Date: Thu, 14 Feb 2002 03:06:49 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6ACE25.1815FACD@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit inline. Let us resolve this quickly, only a few days remain in wglc: Flemming Andreasen wrote: > > > In the case of sendrecv, subsetting is the only thing that makes > sense. > > If A indicates in an offer that it can send and receive with codecs > > 1,2,3, and B indicates in its answer that it can send and receive with > > 2,3,4, the presence of 4 is useless. B can't send with it, since it > > doesn't know whether A can receive it. > > Correct, but A can send with it. So, if A can send with it, but B can't, how is this a sendrecv codec, practically speaking? > > Now, consider the case once more of sendrecv, where A sends 1,2,3 in > the > > offer, and B sends 1,2 in the answer. Can B send with codec 3? No, it > > can't. It can't because A can't send with it, and thus the codec would > > effectively be unidirectional. > > I don't buy that argument since you could equally well have A sending > with 1 > and B sending with 2. True, although that is not the recommended behavior. > > This is a birdirectional stream. So, in > > the case of sendrecv, B needs to be prepared to send and receive with > > the codecs in the answer, and this is what the text says: > > > > -- > > Once the answerer has sent the answer, it {\MUST} be prepared to > > receive media for any recvonly streams described by that answer. It > > {\MUST} be prepared to send and receive media for any sendrecv streams > > in the answer, and {\MAY} send media immediately. > > -- > > > > If the above was the intended implication, then it's not entirely clear. Apparently not.... > > > > Now, in the case of a recvonly offer, A could indicate the ability to > > receive 1,2, and 3. In the answer, lets say B returns 1,2 as sendonly. > > But, then it sends using 3 anyway. If the answerer does not go with > > whats in the answer, the answer provides zero information. The point > of > > the answer in this case is to help the offerer restrict the set of > > codecs it needs to be prepared to receive. > > I thought it was so offerer can figure out what he can actually send > with > (ignoring some of the unidirectional stream cases for a momemt). You've lost me; we are talking explicitly about the unidirectional cases here. > > > I do admit that I find no > > text at the moment which says that the answerer in a sendonly answer > > should send only with the codecs in the answer. However, that has been > > my interprtation. > > I have always understood, that once I hand out an SDP indicating the > ability > to receive codec 1,2, and 3, then I have to be able to receive those > codecs > until I send out another SDP. It is certainly true that you need to be able to receive them once you send them, to handle media clipping. It had been my implicit assumption, arguably not well thought thruough, that the answer would restrict what the element needs to be prepared to receive. I suppose that, since it needs to be able to receive them initially anyway, is there much gained by learning that the set of things to receive is less than it needs to initially? One example is if A can support codecs 1,2,3,4,5, and it sends an offer to B which really only supports 1, and thats what is in the answer. Now, A would still need to be preapred to reeive 1-5 based on your proposal, even though it effectively knows that B is never going to use anythign but 1. I had assumed that the point of the offer/answer exchange was to do a one-pass subsetting of the codecs in use. I am sure we have discussed this in the past in the sip wg. > Of course you can say, that this is > because SDP > never defined the negotiation that offer/answer does, but this seems to > introduce an unnecesary deviation from "normal" SDP usage. I can see that it is a bit odd. I suppose that, if the offerer really wants to know a more restricted set, it can always send an updated offer with fewer codecs, ala the 1-of-N mechanism in the examples in the draft. But, isn't it better to avoid that if you know that the answer defines a subset that is acceptable? > > > > > > > Let me ask the converse - what is gained by having the answerer be > able > > to send with things not in the answer? Why not just include them in > the > > answer? > > It could for example be that I can send RFC 2833 but not receive it. > Admittedly, SDP is not really good at expressing such unidirectional > constraints, and we probably shouldn't get hung up on it (however I > thought > this was one of your concerns). My real concern here is that it seems to > deviate from current SDP behavior. I guess I am confused on this, because we had text along those lines before, and we agreed at ietf 52 to remove it. Specifically, we agreed that, in a sendrecv answer, you cannot add codecs which are recvonly, they have to be sendrecv. From the above, it sounds like you are backing down from that. > > > Same reason as the answerer might want to add a media format not > present > > > in > > > the offer: asymmetry (e.g. I can send RFC 2833 to you, but I > can't > > > receive it). > > > > Remember, we only support asymmetric codecs in asymmetric stream > types. > > We do ? If I offer 2 or more codecs and you answer with two or more > codecs, > then we can have asymmetric codec usage. See above comment; I thought that we agreed that a sendrecv stream had to list sendrecv codecs. > > > > > In the case you describe, you are talking about a recvonly offer and a > > sendonly answer. The spec says that the offer lists the codecs the > > offerer can receive. If its not there, what is gained by adding it in > > the answer? The answerer can't send it anyway, since it doesn't know > if > > the offerer supports it? > > > > However, I thought it would apply to bidirectional streams as well. For > example, if RFC 2833 is not offered , but the answerer is able to accept > it, > he may want to indicate so in the answer (and vice versa). As above, I removed text that explicitly allowed this based on iETF 52 consensus, where we agreed fid was better for it. > > > > > We did previously allow addition of recvonly codecs by the answerer in > a > > sendrecv stream, but agreed at IETF 52 to remove this hack in favor of > > FID, which is the proper way to support such things. I recall you > argued > > in favor of that, even. > > I still do, however that doesn't mean you can't add a sendrecv codec to > a > sendrecv stream, even though you may only be able to send or receive > with it. Perhaps I am being pedantic, but if I am only able to send or receive with it, isn't it not a sendrecv codec? Anyway, I am willing to be flexible here, but to me this is a reasonably big change, and so I'd like to here from other folks..... -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 04:05: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 EAA13781 for ; Thu, 14 Feb 2002 04:05:58 -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 DAA16475; Thu, 14 Feb 2002 03:49:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA16440 for ; Thu, 14 Feb 2002 03:49:30 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13485 for ; Thu, 14 Feb 2002 03:49:27 -0500 (EST) DATE: 14 Feb 2002 08:49:28 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 14 Feb 2002 08:49:28 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA16441 Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Hi Folks, There are enough SIP implementations on the market that would require treating the set of codecs in the offer and the answer as two independent sets. We can decide whatever we want in the standard but interoperability with existing solutions will force people to implement this anyway. Furthermore, the behavior in which offer and answer are treated separately is more generic and includes all possible scenarios. So what I offer is that if offer for sendonly or sendrecv offer contains codecs A, B, C, the answer can contain A, B, D. Additionally answer can use different payload types for A and B. The only requirements are that the offer and the answer contain at least one codec of the same type and the answerer must use the payload types from the offer. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 09:22:05 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 JAA18667 for ; Thu, 14 Feb 2002 09:22:05 -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 JAA00233; Thu, 14 Feb 2002 09:21: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 JAA00190 for ; Thu, 14 Feb 2002 09:21:32 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18657 for ; Thu, 14 Feb 2002 09:21:28 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA09810; Thu, 14 Feb 2002 06:20:41 -0800 (PST) Message-ID: <3C6BC7C5.4A9644D4@cisco.com> Date: Thu, 14 Feb 2002 09:20:53 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Joerg Ott , mmusic@ietf.org, mankin@isi.edu, csp@isi.edu Subject: Re: [MMUSIC] WG Last Call for Offer/Answer References: <3C686DB8.54056FD3@cisco.com> <3C6B5415.DCD401F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Jonathan. Thanks for the responses - I've snipped the ones we are in sync on and/or are being discussed elsewhere. Whatever is left here is really minor. Jonathan Rosenberg wrote: > > > > - p. 4: "The agent receiving the offer MAY generate an answer, or it > > MAY reject the offer.". At least in the unicast case, MUST you not > > always generate an answer which may either accept or reject the offer ? > > No. You can reject the offer outright. In the case of SIP, that would > mean sending > a 488. There is no answer in the 488. OK, however an answer may also reject an offer by rejecting the streams. No big deal. > > > > > p. 10: "The answerer MAY include a ptime" => "The answerer MAY > > include a non-zero ptime" > > I didn't include that restriction for the offer, and you had no comment > on it there. Do I interpret this to mean you want this restriction only > for the answer, or do you really want it for both? Should apply to both. > It had never even > occurred to me to use a zero ptime, I don't even know what that would > mean.... Me neither, but then again I don't think it makes any sense to have bandwidth attributes with a value of zero, but I'll leave that one alone ;-) > > > > > > p. 10: "When sending media, it SHOULD use a packetization interval > > equal to the value of the ptime attribute in the offer, if any was > > present.". Since ptime is a media stream attribute, this can be > > difficult to do if multiple media formats are specified. There should be > > a rounding rule to account for that (e.g. use closest non-zero ptime if > > you can't use the ptime specified). > > This is really a general SDP issue, not specific to O/A. Do we want to > discuss it here? Probably sdp-new should clarify this. > Good point (only minor issue then is that we are referencing RFC 2327 throughout, and not sdp-new). > > > > > p. 11: "Similarly, the directionality information in the answer > > (sendonly, recvonly, or sendrecv) MUST equal that of the offer." It may > > be worth spelling it out more clearly what this means, since it differs > > from the unicast. > > I mention it in the text on constructing the offer, see above response. I still think it's worth spelling it out, since the less than careful reader may not pick up on it. Not a big deal. > > > > > > p. 13: "Removal of a media stream implies that media is no longer > > sent for that stream.". Add sentence "Furthermore, when RTP was used for > > the media stream, RTCP reports will no longer be sent or received." > > Added: > > In the case of RTP, RTCP transmission also ceases. Not only that, you also will not accept any incoming RTCP messages, right (transmission only implies sending) ? > > > > > Section 8.4: Section seems to be unicast specific. Both heading and > > section text should reflect this. > > I changed the section heading to "putting a unicast stream on hold". I > see no need to repeat that within the body text. > I like being explict but OK. How about at least adding "unicast" in the first paragraph, i.e. "one or more media streams" => "one or more unicast media streams". > > > > Section 9: "The transport component of the "m=" line indicates the > > preferred transport for that media type.". Not sure this is ideal. For > > example, if I support both RTP and SRTP, do I only indicate one of them > > (similar issue with T.38 UDP or TCP) ? > > Yes. Its not really preferred, its "the one". If you want to indicate > support for both SRTP and RTP, you would pick one in the offer, include > simcaps indicating the other. Similar in the answer. THe offerer could > then send an updated offer switching to SRTP. This is discussed in the > unify draft. Never mind - I got confused on OPTIONS for a second. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 10:07: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 KAA23743 for ; Thu, 14 Feb 2002 10:07:19 -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 KAA02641; Thu, 14 Feb 2002 10:06: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 KAA02608 for ; Thu, 14 Feb 2002 10:06:47 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23724 for ; Thu, 14 Feb 2002 10:06:43 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA23452; Thu, 14 Feb 2002 07:06:01 -0800 (PST) Message-ID: <3C6BD265.4E7BF51B@cisco.com> Date: Thu, 14 Feb 2002 10:06:13 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6ACE25.1815FACD@cisco.com> <3C6B7019.8EB4FCDE@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > inline. Let us resolve this quickly, only a few days remain in wglc: > > Flemming Andreasen wrote: > > > > > > In the case of sendrecv, subsetting is the only thing that makes > > sense. > > > If A indicates in an offer that it can send and receive with codecs > > > 1,2,3, and B indicates in its answer that it can send and receive with > > > 2,3,4, the presence of 4 is useless. B can't send with it, since it > > > doesn't know whether A can receive it. > > > > Correct, but A can send with it. > > So, if A can send with it, but B can't, how is this a sendrecv codec, > practically speaking? It is a sendrecv codec inasmuch, that if B sends an offer with this codec (as sendrecv), it knows that A can actually support it. > > > > > > > Now, in the case of a recvonly offer, A could indicate the ability to > > > receive 1,2, and 3. In the answer, lets say B returns 1,2 as sendonly. > > > But, then it sends using 3 anyway. If the answerer does not go with > > > whats in the answer, the answer provides zero information. The point > > of > > > the answer in this case is to help the offerer restrict the set of > > > codecs it needs to be prepared to receive. > > > > I thought it was so offerer can figure out what he can actually send > > with > > (ignoring some of the unidirectional stream cases for a momemt). > > You've lost me; we are talking explicitly about the unidirectional cases > here. > I thought you were referring to offer/answer in general. The purpose of an offer/answer should be the same for unidirectional and bidirectional media streams. The question in general is, if A sends an offer indicating willingness to receive codecs 1,2, and 3, and B sends an answer omitting one or more of these codecs, is A still obligated to receive all three codecs. I don't see this as a unidirectional stream issue only. > > > > > > I do admit that I find no > > > text at the moment which says that the answerer in a sendonly answer > > > should send only with the codecs in the answer. However, that has been > > > my interprtation. > > > > I have always understood, that once I hand out an SDP indicating the > > ability > > to receive codec 1,2, and 3, then I have to be able to receive those > > codecs > > until I send out another SDP. > > It is certainly true that you need to be able to receive them once you > send them, to handle media clipping. It had been my implicit assumption, > arguably not well thought thruough, that the answer would restrict what > the element needs to be prepared to receive. I suppose that, since it > needs to be able to receive them initially anyway, is there much gained > by learning that the set of things to receive is less than it needs to > initially? > There is, but in the process, we loose some abilities too. Since we could effectively achieve the same by issuing a new offer with the "answer" set of codecs, I'm not convinced this is a good trade-off. > > One example is if A can support codecs 1,2,3,4,5, and it sends an offer > to B which really only supports 1, and thats what is in the answer. Now, > A would still need to be preapred to reeive 1-5 based on your proposal, > even though it effectively knows that B is never going to use anythign > but 1. That's where we differ - I don't think A can make that assumption. > I had assumed that the point of the offer/answer exchange was to > do a one-pass subsetting of the codecs in use. I am sure we have > discussed this in the past in the sip wg. > > > > Of course you can say, that this is > > because SDP > > never defined the negotiation that offer/answer does, but this seems to > > introduce an unnecesary deviation from "normal" SDP usage. > > I can see that it is a bit odd. > > I suppose that, if the offerer really wants to know a more restricted > set, it can always send an updated offer with fewer codecs, ala the > 1-of-N mechanism in the examples in the draft. But, isn't it better to > avoid that if you know that the answer defines a subset that is > acceptable? We loose something in the process as described above, and hence I'm not convinced. Also, I am concerned about deviating from "normal" SDP usage (the way I've understood it so far at least). > > > > > > > > > > > Let me ask the converse - what is gained by having the answerer be > > able > > > to send with things not in the answer? Why not just include them in > > the > > > answer? > > > > It could for example be that I can send RFC 2833 but not receive it. > > Admittedly, SDP is not really good at expressing such unidirectional > > constraints, and we probably shouldn't get hung up on it (however I > > thought > > this was one of your concerns). My real concern here is that it seems to > > deviate from current SDP behavior. > > I guess I am confused on this, because we had text along those lines > before, and we agreed at ietf 52 to remove it. Specifically, we agreed > that, in a sendrecv answer, you cannot add codecs which are recvonly, > they have to be sendrecv. From the above, it sounds like you are backing > down from that. No - I'm still saying that if an agent lists a media formats listed in a sendrecv stream then the agent must support that media format bidirectionally (regardless of whether the context implies that it can only be used unidirectionally). In the above example, if the (sendrecv) offer contains RFC 2833, but the answer does not, the answerer might still be able to send with RFC 2833, but not receive it (which is why he didn't include it in the answer). > > > > > > Same reason as the answerer might want to add a media format not > > present > > > > in > > > > the offer: asymmetry (e.g. I can send RFC 2833 to you, but I > > can't > > > > receive it). > > > > > > Remember, we only support asymmetric codecs in asymmetric stream > > types. > > > > We do ? If I offer 2 or more codecs and you answer with two or more > > codecs, > > then we can have asymmetric codec usage. > > See above comment; I thought that we agreed that a sendrecv stream had > to list sendrecv codecs. > We still do, however whether the context in which is supplied may still lead to it only being usable in one direction. If the context changes, then maybe it can be used bidirectionally. > > > > > > > > > In the case you describe, you are talking about a recvonly offer and a > > > sendonly answer. The spec says that the offer lists the codecs the > > > offerer can receive. If its not there, what is gained by adding it in > > > the answer? The answerer can't send it anyway, since it doesn't know > > if > > > the offerer supports it? > > > > > > > However, I thought it would apply to bidirectional streams as well. For > > example, if RFC 2833 is not offered , but the answerer is able to accept > > it, > > he may want to indicate so in the answer (and vice versa). > > As above, I removed text that explicitly allowed this based on iETF 52 > consensus, where we agreed fid was better for it. > I believe that was different inasmuch as that was referring to unidirectional capabilities on bidirectional streams. If I recall correctly, the fid-draft would allow the offerer to indicate unidirectional capabilities, and have the answerer respond accordingly. However, the answerer cannot add media streams to indicate unidirectional capabilities in response to bidirectional media stream. What I am talking about is bidirectional capabilities on bidirectional streams, however the context may imply that the flow of a particular media format can only occur in one direction (e.g. because only the offer or the answer contained that media format). > > > > > > We did previously allow addition of recvonly codecs by the answerer in > > a > > > sendrecv stream, but agreed at IETF 52 to remove this hack in favor of > > > FID, which is the proper way to support such things. I recall you > > argued > > > in favor of that, even. > > > > I still do, however that doesn't mean you can't add a sendrecv codec to > > a > > sendrecv stream, even though you may only be able to send or receive > > with it. > > Perhaps I am being pedantic, but if I am only able to send or receive > with it, isn't it not a sendrecv codec? It may only be able to be used unidirectionally in the currect context, however if the context changes, we know that it is supported bidirectionally (3pcc for example). > > Anyway, I am willing to be flexible here, but to me this is a reasonably > big change, Maybe from the current text, but the discussions we had on the previous version of the draft at least was intended to convey the above. -- Flemming > and so I'd like to here from other folks..... > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 11:04: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 LAA25405 for ; Thu, 14 Feb 2002 11:04:52 -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 LAA06633; Thu, 14 Feb 2002 11:04: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 LAA06598 for ; Thu, 14 Feb 2002 11:04:28 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25400 for ; Thu, 14 Feb 2002 11:04:25 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EG4e6Y001512; Thu, 14 Feb 2002 11:04:40 -0500 (EST) Message-ID: <3C6BDFE7.C4D3CFD1@dynamicsoft.com> Date: Thu, 14 Feb 2002 11:03:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Joerg Ott , mmusic@ietf.org, mankin@isi.edu, csp@isi.edu Subject: Re: [MMUSIC] WG Last Call for Offer/Answer References: <3C6BC7C5.4A9644D4@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > > > - p. 4: "The agent receiving the offer MAY generate an answer, or > it > > > MAY reject the offer.". At least in the unicast case, MUST you not > > > always generate an answer which may either accept or reject the > offer ? > > > > No. You can reject the offer outright. In the case of SIP, that would > > mean sending > > a 488. There is no answer in the 488. > > OK, however an answer may also reject an offer by rejecting the streams. > No > big deal. Right, of course. However, there is still in answer in that case. So, the two cases still remain - MAY generate an answer, or MAY reject it. > > > > > > > > > p. 10: "The answerer MAY include a ptime" => "The answerer MAY > > > include a non-zero ptime" > > > > I didn't include that restriction for the offer, and you had no > comment > > on it there. Do I interpret this to mean you want this restriction > only > > for the answer, or do you really want it for both? > > Should apply to both. I'll add nonzero, but I suspect most folks wouldn't have even thought to put zero in there. > > > > > > > > > > > p. 10: "When sending media, it SHOULD use a packetization > interval > > > equal to the value of the ptime attribute in the offer, if any was > > > present.". Since ptime is a media stream attribute, this can be > > > difficult to do if multiple media formats are specified. There > should be > > > a rounding rule to account for that (e.g. use closest non-zero ptime > if > > > you can't use the ptime specified). > > > > This is really a general SDP issue, not specific to O/A. Do we want to > > discuss it here? Probably sdp-new should clarify this. > > > > Good point (only minor issue then is that we are referencing RFC 2327 > throughout, and not sdp-new). I'd rather not discuss this in O/A, even if we only refer to 2327. In reality, people can and will look at sdp-new. What we do need to do is make sure that the text on this goes into sdp-new... > > > > > > > > > p. 11: "Similarly, the directionality information in the answer > > > (sendonly, recvonly, or sendrecv) MUST equal that of the offer." It > may > > > be worth spelling it out more clearly what this means, since it > differs > > > from the unicast. > > > > I mention it in the text on constructing the offer, see above > response. > > I still think it's worth spelling it out, since the less than careful > reader > may not pick up on it. Not a big deal. OK. I added this: This is because all participants in a multicast session need to have equivalent views of the parameters of the session, and underlying assumption of the multicast bias of RFC 2327. > > > > > > > > > > > p. 13: "Removal of a media stream implies that media is no longer > > > sent for that stream.". Add sentence "Furthermore, when RTP was used > for > > > the media stream, RTCP reports will no longer be sent or received." > > > > Added: > > > > In the case of RTP, RTCP transmission also ceases. > > Not only that, you also will not accept any incoming RTCP messages, > right > (transmission only implies sending) ? True, and then I need to say the same for the RTP itself, since the text also only says to stop sending. I'll change. It now reads: Removal of a media stream implies that media is no longer sent for that stream, and any media that is received is discarded. In the case of RTP, RTCP transmission also ceases, as does processing of any received RTCP packets. > > > > > > > > > Section 8.4: Section seems to be unicast specific. Both heading > and > > > section text should reflect this. > > > > I changed the section heading to "putting a unicast stream on hold". I > > see no need to repeat that within the body text. > > > > I like being explict but OK. How about at least adding "unicast" in the > first > paragraph, i.e. "one or more media streams" => "one or more unicast > media > streams". Done. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 11:08: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 LAA25566 for ; Thu, 14 Feb 2002 11:08: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 LAA06786; Thu, 14 Feb 2002 11:08: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 LAA06751 for ; Thu, 14 Feb 2002 11:08:18 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25542 for ; Thu, 14 Feb 2002 11:08:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EG8V6Y001515; Thu, 14 Feb 2002 11:08:31 -0500 (EST) Message-ID: <3C6BE0CE.728E0AC8@dynamicsoft.com> Date: Thu, 14 Feb 2002 11:07:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: fandreas@cisco.com, mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > > Jonathan D. Rosenberg wrote: > > > Let me ask the converse - what is gained by having the answerer be > able > > to send with things not in the answer? Why not just include them in > the > > answer? > > This is primarily a question of interpretation. I know at least one > gateway implementation which is capable of sending, but not receiving > avt tones. So this gateway replies to a sendrecv offer, which contains > avt tones and G.711, with an answer that contains only G.711, but sends > out avt tones anyway. I am looking for the language that states whether > this behavior is legal or not. I had text that allowed exactly this in the previous version, for exactly this reason. Consensus at the last IETF was to remove it. The reason was, that in a sendrecv stream, the codecs you list have to be sendrecv codecs. I think that all of the confusion here is about the interpretation of what it means to be a "sendrecv" codec... please see my response to Flemming. Just as a note, we have a DROP DEAD date for completion of this document by monday, so let us not let this thread die! So far so good, but I just want to be sure folks are aware of the time pressures we are under. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 11:11: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 LAA25663 for ; Thu, 14 Feb 2002 11:11: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 LAA07335; Thu, 14 Feb 2002 11:11: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 LAA07263 for ; Thu, 14 Feb 2002 11:11:00 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25651 for ; Thu, 14 Feb 2002 11:10:56 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA20421; Thu, 14 Feb 2002 08:10:14 -0800 (PST) Message-ID: <3C6BE172.92D5DE7A@cisco.com> Date: Thu, 14 Feb 2002 11:10:26 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Joerg Ott , mmusic@ietf.org, mankin@isi.edu, csp@isi.edu Subject: Re: [MMUSIC] WG Last Call for Offer/Answer References: <3C6BC7C5.4A9644D4@cisco.com> <3C6BDFE7.C4D3CFD1@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Looks good. Thanks a lot Flemming Jonathan Rosenberg wrote: > Flemming Andreasen wrote: > > > > > > - p. 4: "The agent receiving the offer MAY generate an answer, or > > it > > > > MAY reject the offer.". At least in the unicast case, MUST you not > > > > always generate an answer which may either accept or reject the > > offer ? > > > > > > No. You can reject the offer outright. In the case of SIP, that would > > > mean sending > > > a 488. There is no answer in the 488. > > > > OK, however an answer may also reject an offer by rejecting the streams. > > No > > big deal. > > Right, of course. However, there is still in answer in that case. So, > the two cases still remain - MAY generate an answer, or MAY reject it. > > > > > > > > > > > > > > p. 10: "The answerer MAY include a ptime" => "The answerer MAY > > > > include a non-zero ptime" > > > > > > I didn't include that restriction for the offer, and you had no > > comment > > > on it there. Do I interpret this to mean you want this restriction > > only > > > for the answer, or do you really want it for both? > > > > Should apply to both. > > I'll add nonzero, but I suspect most folks wouldn't have even thought to > put zero in there. > > > > > > > > > > > > > > > > > p. 10: "When sending media, it SHOULD use a packetization > > interval > > > > equal to the value of the ptime attribute in the offer, if any was > > > > present.". Since ptime is a media stream attribute, this can be > > > > difficult to do if multiple media formats are specified. There > > should be > > > > a rounding rule to account for that (e.g. use closest non-zero ptime > > if > > > > you can't use the ptime specified). > > > > > > This is really a general SDP issue, not specific to O/A. Do we want to > > > discuss it here? Probably sdp-new should clarify this. > > > > > > > Good point (only minor issue then is that we are referencing RFC 2327 > > throughout, and not sdp-new). > > I'd rather not discuss this in O/A, even if we only refer to 2327. In > reality, people can and will look at sdp-new. What we do need to do is > make sure that the text on this goes into sdp-new... > > > > > > > > > > > > > > p. 11: "Similarly, the directionality information in the answer > > > > (sendonly, recvonly, or sendrecv) MUST equal that of the offer." It > > may > > > > be worth spelling it out more clearly what this means, since it > > differs > > > > from the unicast. > > > > > > I mention it in the text on constructing the offer, see above > > response. > > > > I still think it's worth spelling it out, since the less than careful > > reader > > may not pick up on it. Not a big deal. > > OK. I added this: > > This is because all > participants in a multicast session need to have equivalent views of > the parameters of the session, and underlying assumption of the > multicast bias of RFC 2327. > > > > > > > > > > > > > > > > > p. 13: "Removal of a media stream implies that media is no longer > > > > sent for that stream.". Add sentence "Furthermore, when RTP was used > > for > > > > the media stream, RTCP reports will no longer be sent or received." > > > > > > Added: > > > > > > In the case of RTP, RTCP transmission also ceases. > > > > Not only that, you also will not accept any incoming RTCP messages, > > right > > (transmission only implies sending) ? > > True, and then I need to say the same for the RTP itself, since the text > also only says to stop sending. I'll change. It now reads: > > Removal of a media stream implies that media is no longer sent for > that stream, and any media that is received is discarded. In the case > of RTP, RTCP transmission also ceases, as does processing of any > received RTCP packets. > > > > > > > > > > > > > > Section 8.4: Section seems to be unicast specific. Both heading > > and > > > > section text should reflect this. > > > > > > I changed the section heading to "putting a unicast stream on hold". I > > > see no need to repeat that within the body text. > > > > > > > I like being explict but OK. How about at least adding "unicast" in the > > first > > paragraph, i.e. "one or more media streams" => "one or more unicast > > media > > streams". > > Done. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 12:36:06 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 MAA00726 for ; Thu, 14 Feb 2002 12:36: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 MAA14150; Thu, 14 Feb 2002 12:35: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 MAA14117 for ; Thu, 14 Feb 2002 12:35:48 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00723 for ; Thu, 14 Feb 2002 12:35:44 -0500 (EST) DATE: 14 Feb 2002 17:35:47 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 14 Feb 2002 17:35:47 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id MAA14118 Subject: [MMUSIC] Re: Re: Using payload types not specified in answer in offer/answer 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 Jonathan D. Rosenberg wrote: > Just as a note, we have a DROP DEAD date for completion of this document > by monday, so let us not let this thread die! So far so good, but I just > want to be sure folks are aware of the time pressures we are under. I understand the time pressure. All I want is to have a consistent behavior specified by the standard. The original rfc2543 use to specify in section B.2: If the media stream is listed as both send and receive, the callee lists those codecs it is capable of sending or receiving among the ones listed by the caller in the INVITE. Starting from rfc2543bis3 it it changed to (Section B.2.1): If multiple codecs are listed, it means that the offerer is capable of making use of any of those codecs during the call. In other words, the answerer MAY change codecs in the middle of the call, without sending a SIP message, to make use of any of those listed. Once again, there are enough rfc2543bis3 compliant implementations out there to justify not changing the offer/answer behavior once more. The later model can easily be implemented, since the support for it is already in place for early media. In any case, we should at least specify that the offerer MUST accept all the codecs from the original offer, regardless whether the answerer MAY or SHOULD not send using any codecs not specified in the answer. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 13:39:21 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 NAA05666 for ; Thu, 14 Feb 2002 13:39:21 -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 NAA17113; Thu, 14 Feb 2002 13:38: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 NAA17078 for ; Thu, 14 Feb 2002 13:38:48 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05644 for ; Thu, 14 Feb 2002 13:38:45 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1EIcv6Y001735; Thu, 14 Feb 2002 13:38:57 -0500 (EST) Message-ID: <3C6C0411.92C16957@dynamicsoft.com> Date: Thu, 14 Feb 2002 13:38:09 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Roman Shpount , mmusic@ietf.org, Jonathan Rosenberg Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6BD265.4E7BF51B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > I thought you were referring to offer/answer in general. The purpose of > an > offer/answer should be the same for unidirectional and bidirectional > media > streams. The question in general is, if A sends an offer indicating > willingness to receive codecs 1,2, and 3, and B sends an answer omitting > one > or more of these codecs, is A still obligated to receive all three > codecs. I > don't see this as a unidirectional stream issue only. That is the question, indeed. So, I sent private emails to a bunch of folks who I suspect have an opinion, but who haven't been following the threads (I fear that the huge volume that has been going on on the lists, and the fast pace, have pushed a lot of people out of touch). All of the replies I got (about 5) indicated that peoples interpretations had been the same as yours and Roman's, with one person waffling a bit. So, in the interests of progress and rough consensus, I will declare myself in the apparent minority. I see and understand the points Flemming is making; I don't think either side is technicall incorrect, it is merely an issue of interpretation. I will change the text to indicate that the offerer needs to be prepared to always receive any of them, and that the answerer can send with ones not present in the answer (but won't receive, obviously). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 13:54: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 NAA06117 for ; Thu, 14 Feb 2002 13:54: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 NAA17984; Thu, 14 Feb 2002 13:53:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17949 for ; Thu, 14 Feb 2002 13:53:32 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06087 for ; Thu, 14 Feb 2002 13:53:29 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA12854; Thu, 14 Feb 2002 10:52:50 -0800 (PST) Message-ID: <3C6C078D.ABC1497C@cisco.com> Date: Thu, 14 Feb 2002 13:53:01 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Roman Shpount , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6BD265.4E7BF51B@cisco.com> <3C6C0411.92C16957@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Sounds good - that addresses all of my comments then. Thanks a lot for all your hard work on this. -- Flemming Jonathan Rosenberg wrote: > Flemming Andreasen wrote: > > > > > I thought you were referring to offer/answer in general. The purpose of > > an > > offer/answer should be the same for unidirectional and bidirectional > > media > > streams. The question in general is, if A sends an offer indicating > > willingness to receive codecs 1,2, and 3, and B sends an answer omitting > > one > > or more of these codecs, is A still obligated to receive all three > > codecs. I > > don't see this as a unidirectional stream issue only. > > That is the question, indeed. > > So, I sent private emails to a bunch of folks who I suspect have an > opinion, but who haven't been following the threads (I fear that the > huge volume that has been going on on the lists, and the fast pace, have > pushed a lot of people out of touch). All of the replies I got (about 5) > indicated that peoples interpretations had been the same as yours and > Roman's, with one person waffling a bit. > > So, in the interests of progress and rough consensus, I will declare > myself in the apparent minority. I see and understand the points > Flemming is making; I don't think either side is technicall incorrect, > it is merely an issue of interpretation. I will change the text to > indicate that the offerer needs to be prepared to always receive any of > them, and that the answerer can send with ones not present in the answer > (but won't receive, obviously). > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 15:51:10 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 PAA09364 for ; Thu, 14 Feb 2002 15:51:10 -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 PAA25886; Thu, 14 Feb 2002 15:50:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25853 for ; Thu, 14 Feb 2002 15:50:42 -0500 (EST) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09352 for ; Thu, 14 Feb 2002 15:50:37 -0500 (EST) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id OAA03545 for ; Thu, 14 Feb 2002 14:53:51 -0600 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 14 Feb 2002 14:34:05 -0600 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Thu, 14 Feb 2002 14:49:46 -0600 From: "Bert Culpepper" To: "'Jonathan Rosenberg'" , "'Flemming Andreasen'" Cc: "'Roman Shpount'" , Subject: RE: [MMUSIC] Re: Using payload types not specified in answer in offer/answer Date: Thu, 14 Feb 2002 15:49:36 -0500 Message-ID: <003f01c1b599$1e36dbe0$7397d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3C6C0411.92C16957@dynamicsoft.com> Importance: Normal 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 I was trying to find a place to jump in (with all the traffic and its pace :) but I see I'm late now. I'll say my 2 cents anyway... I always thought not getting an affirmative indication of what a sender will send was a deficiency in the protocol. For a multi-session platform that wants to optimize its resources, this behavior is not desirable if its goal is to try to find one format the other end supports. In order to minimize resource usage (i.e., not allocate DSP resources for formats that will probably not be used in the session), I can only "advertise" what I'm willing to reserve. Which will be a single encoding format in almost all cases. I liked where Jonathan was going, but I understand consensus... If I look at the case where a gateway can send rfc2833 and an endpoint wants it, I would prefer to see the gateway "advertise" support with the sendonly attribute rather than it saying nothing. Regards, Bert > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Thursday, February 14, 2002 1:38 PM > To: Flemming Andreasen > Cc: Roman Shpount; mmusic@ietf.org; Jonathan Rosenberg > Subject: Re: [MMUSIC] Re: Using payload types not specified > in answer in > offer/answer > > > > > Flemming Andreasen wrote: > > > > > I thought you were referring to offer/answer in general. > The purpose of > > an > > offer/answer should be the same for unidirectional and bidirectional > > media > > streams. The question in general is, if A sends an offer indicating > > willingness to receive codecs 1,2, and 3, and B sends an > answer omitting > > one > > or more of these codecs, is A still obligated to receive all three > > codecs. I > > don't see this as a unidirectional stream issue only. > > That is the question, indeed. > > So, I sent private emails to a bunch of folks who I suspect have an > opinion, but who haven't been following the threads (I fear that the > huge volume that has been going on on the lists, and the fast > pace, have > pushed a lot of people out of touch). All of the replies I > got (about 5) > indicated that peoples interpretations had been the same as yours and > Roman's, with one person waffling a bit. > > So, in the interests of progress and rough consensus, I will declare > myself in the apparent minority. I see and understand the points > Flemming is making; I don't think either side is technicall incorrect, > it is merely an issue of interpretation. I will change the text to > indicate that the offerer needs to be prepared to always > receive any of > them, and that the answerer can send with ones not present in > the answer > (but won't receive, obviously). > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 16:08: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 QAA09820 for ; Thu, 14 Feb 2002 16:08:11 -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 QAA27021; Thu, 14 Feb 2002 16:07:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA26988 for ; Thu, 14 Feb 2002 16:07:41 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09784 for ; Thu, 14 Feb 2002 16:07:36 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA07942; Thu, 14 Feb 2002 13:06:53 -0800 (PST) Message-ID: <3C6C26F6.F0D424FE@cisco.com> Date: Thu, 14 Feb 2002 16:07:02 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper CC: "'Jonathan Rosenberg'" , "'Roman Shpount'" , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <003f01c1b599$1e36dbe0$7397d697@bculpepperpc> 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 Bert Culpepper wrote: > I was trying to find a place to jump in (with all the traffic and its pace > :) but I see I'm late now. I'll say my 2 cents anyway... > > I always thought not getting an affirmative indication of what a sender will > send was a deficiency in the protocol. For a multi-session platform that > wants to optimize its resources, this behavior is not desirable if its goal > is to try to find one format the other end supports. In order to minimize > resource usage (i.e., not allocate DSP resources for formats that will > probably not be used in the session), I can only "advertise" what I'm > willing to reserve. Which will be a single encoding format in almost all > cases. I liked where Jonathan was going, but I understand consensus... > Also note, that you can achieve almost the same by issuing an updated offer/answer with the the single codec, if that's what you want. > > If I look at the case where a gateway can send rfc2833 and an endpoint wants > it, I would prefer to see the gateway "advertise" support with the sendonly > attribute rather than it saying nothing. There's only so much we can do within the existing semantics of SDP, however you can still use the fid-draft to provide unidirectional media formats in an offer - you just can't add it to the answer if it the offer didn't contain it. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 18:43:10 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 SAA12794 for ; Thu, 14 Feb 2002 18:43:10 -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 SAA03726; Thu, 14 Feb 2002 18:42:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03693 for ; Thu, 14 Feb 2002 18:42:50 -0500 (EST) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12782 for ; Thu, 14 Feb 2002 18:42:46 -0500 (EST) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id RAA04340 for ; Thu, 14 Feb 2002 17:46:01 -0600 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 14 Feb 2002 17:26:14 -0600 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Thu, 14 Feb 2002 17:41:52 -0600 From: "Bert Culpepper" To: "'Flemming Andreasen'" Cc: "'Jonathan Rosenberg'" , "'Roman Shpount'" , Subject: RE: [MMUSIC] Re: Using payload types not specified in answer in offer/answer Date: Thu, 14 Feb 2002 18:41:42 -0500 Message-ID: <004501c1b5b1$28955a40$7397d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3C6C26F6.F0D424FE@cisco.com> Importance: Normal 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 > > Also note, that you can achieve almost the same by issuing an updated > offer/answer with the the single codec, if that's what you want. I shouldn't be in so much of a hurry to jump in...You're right, with an extra message exchange I can satisfy both goals. This will work for me. Thanks, Bert _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 14 21: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 VAA15994 for ; Thu, 14 Feb 2002 21:37: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 VAA10223; Thu, 14 Feb 2002 21:36:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10191 for ; Thu, 14 Feb 2002 21:36:26 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15785 for ; Thu, 14 Feb 2002 21:34:55 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.42]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1F2Z76Y002469; Thu, 14 Feb 2002 21:35:08 -0500 (EST) Message-ID: <3C6C73A7.17B4344F@dynamicsoft.com> Date: Thu, 14 Feb 2002 21:34:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Culpepper CC: "'Flemming Andreasen'" , "'Roman Shpount'" , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <004501c1b5b1$28955a40$7397d697@bculpepperpc> 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 I got some more responses in private, and also noodled over this some more. I still have a queasy feeling. The question is really fundamental. What is the "answer" in an O/A exchange? Is it a declaration, as is the offer, which are not much related, or is it a negotiation to arrive at agreed upon parameters? One way to figure it out is to look at other aspects of the SDP negotiation. Consider the a=sendrecv, a=sendonly, a=recvonly attributes. If A sends an offer, with the stream as sendrecv, and the answer (from B) says recvonly, here is the question. Can B now send to A? If you believe that the directional attributes are a shared, negotiated view of the session, which has been my interpetation, the answer is NO. This stream is from A to B, period. If you believe that B always can do whatever is declared to it in the offer, the answer is yes - A can receive, so B should be able to send. Really, the offer/answer model has some attributes which are merely declarative (like ptime), and others which are shared and negotiated (directionality). Therefore, the argument that SDP is always declarative holds no ground, since I think (hope) we can agree that there are most definitely attributes which are shared and negotiated. So, are, or are not, codecs part of this? If the goal, in general, is for a common codec to be used in each direction, then I think the view has to be that they are shared. While we could just reduce the set later with an additional offer, as Flemming has pointed out, the value that the O/A exchange brings to the table is the ability to not need to do that. Thanks, Jonathan R. Bert Culpepper wrote: > > > > > Also note, that you can achieve almost the same by issuing an updated > > offer/answer with the the single codec, if that's what you want. > > I shouldn't be in so much of a hurry to jump in...You're right, with an > extra message exchange I can satisfy both goals. This will work for me. > > Thanks, > Bert -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 03: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 DAA29597 for ; Fri, 15 Feb 2002 03:24:55 -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 DAA04776; Fri, 15 Feb 2002 03:24:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04746 for ; Fri, 15 Feb 2002 03:24:14 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA29575 for ; Fri, 15 Feb 2002 03:24:12 -0500 (EST) SUBJECT: Re: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer DATE: 15 Feb 2002 08:24:12 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 15 Feb 2002 08:24:12 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Cc: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id DAA04747 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 I would definitely agree with Jonathan in his point of view about codec negotiation if we had a luxury of defining a new standard. Unfortunately what is being done here (at least from my point of view) is just an attempt to ensure interoperability of existing applications. My suggestion for this standard would be something along the lines: Offerer MUST accept all the codecs from the original offer. Answerer SHOULD NOT send using any codecs not specified in the answer. This way we have implementations compatible with both rfc2543 and rfc2543bis3. It is a compromise that I think should always work. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 04:30: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 EAA00848 for ; Fri, 15 Feb 2002 04:30:08 -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 EAA08426; Fri, 15 Feb 2002 04:29: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 EAA08398 for ; Fri, 15 Feb 2002 04:29:36 -0500 (EST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00826 for ; Fri, 15 Feb 2002 04:29:33 -0500 (EST) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id SAA10688 for ; Fri, 15 Feb 2002 18:29:34 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20020131) with ESMTP id SAA07331 for ; Fri, 15 Feb 2002 18:29:34 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/02/13/02) with ESMTP id SAA03352 for ; Fri, 15 Feb 2002 18:29:33 +0900 (JST) (envelope-from waki.hiroshi@lab.ntt.co.jp) Received: from imf.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id SAA05364 for ; Fri, 15 Feb 2002 18:29:32 +0900 (JST) Received: from pikmin by imf.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id SAA02310 for ; Fri, 15 Feb 2002 18:29:32 +0900 (JST) Message-ID: <14c501c1b603$45b6ce90$e10a3c81@pikmin> From: "Hiroshi Waki" To: Date: Fri, 15 Feb 2002 18:29:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Answerers alternative selection of m lines(one IPv4 and the other IPv6) 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, Suppose the offerer is dual stack and does not know which version of IP is supported by the answerer. The answerer may support both or only one IP version, either v4 or v6. In this case, the offerer may use the offer that includes two m lines (one IPv4 and the other IPv6) grouped using FID. Both lines contains the same codec(s). What the offerer expects is that the answerer selects only one of the two m lines, i.e. the answerer accepts one m line with an appropriate port, and explicitly rejects the other m line with port=0 in the corresponding m lines in the answer. However, the answerer may accept both of them, and if so, it means that two RTP sessions at the same time, as the draft-ietf-mmusic-fid-05 says, 'Remember that if several "m" lines grouped together using FID semantics contain the same codec the media agent MUST send media over several RTP sessions at the same time' in 7.4.1. How can the offerer prevent it? Do we need a new mechanism to show "alternative" m lines to let the answer know that it must select only one of them? Regards, Hiroshi Waki NTT Network Service Systems Laboratories tel +81 422 59 3404 fax +81 422 59 3494 e-mail waki.hiroshi@lab.ntt.co.jp _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 10:03: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 KAA07356 for ; Fri, 15 Feb 2002 10:03:42 -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 KAA23985; Fri, 15 Feb 2002 10:03: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 KAA23950 for ; Fri, 15 Feb 2002 10:03:01 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07339 for ; Fri, 15 Feb 2002 10:02:59 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA25061; Fri, 15 Feb 2002 07:02:21 -0800 (PST) Message-ID: <3C6D2308.ABE52211@cisco.com> Date: Fri, 15 Feb 2002 10:02:33 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Bert Culpepper , "'Roman Shpount'" , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <004501c1b5b1$28955a40$7397d697@bculpepperpc> <3C6C73A7.17B4344F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Really, the offer/answer model has some attributes which are merely > declarative (like ptime), and others which are shared and negotiated > (directionality). Therefore, the argument that SDP is always declarative > holds no ground, since I think (hope) we can agree that there are most > definitely attributes which are shared and negotiated. So, are, or are > not, codecs part of this? If the goal, in general, is for a common codec > to be used in each direction, then I think the view has to be that they > are shared. While we could just reduce the set later with an additional > offer, as Flemming has pointed out, the value that the O/A exchange > brings to the table is the ability to not need to do that. Actually, it doesn't. With the present O/A text, we already have to support all codecs in the offer until we get the answer. Furthermore, since the offerer has no control over the answer, it is quite possible that the answer contains more than one of the offered codec, and hence we are back where we started. The only way to get down to one codec is a new offer/answer exchange. Thus, the above can at most be seen as a possible optimization between offerers and answerers that both agree to pick just one codec. Since it doesn't really solve the problem then, we loose some functionality in the process, and we depart with what at least a lot of people had understood (based on your earlier e-mail), we should stick to yesterday's consensus. -- Flemming > > > Thanks, > Jonathan R. > > Bert Culpepper wrote: > > > > > > > > Also note, that you can achieve almost the same by issuing an updated > > > offer/answer with the the single codec, if that's what you want. > > > > I shouldn't be in so much of a hurry to jump in...You're right, with an > > extra message exchange I can satisfy both goals. This will work for me. > > > > Thanks, > > Bert > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 10:08: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 KAA07525 for ; Fri, 15 Feb 2002 10:08:10 -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 KAA24461; Fri, 15 Feb 2002 10:07:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA24424 for ; Fri, 15 Feb 2002 10:07:42 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07516 for ; Fri, 15 Feb 2002 10:07:40 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA26763; Fri, 15 Feb 2002 07:07:00 -0800 (PST) Message-ID: <3C6D2420.D94751D9@cisco.com> Date: Fri, 15 Feb 2002 10:07:12 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: jdrosen@dynamicsoft.com, bert.culpepper@intervoice-brite.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > I would definitely agree with Jonathan in his point of view about codec negotiation if we had a luxury of defining a new standard. Unfortunately what is being done here (at least from my point of view) is just an attempt to ensure interoperability of existing applications. My suggestion for this standard would be something along the lines: > > Offerer MUST accept all the codecs from the original offer. Answerer > SHOULD NOT send using any codecs not specified in the answer. > "SHOULD NOT" is not to be taken lightly, and hence this effectively says that you can only use the codecs in the answer. As I indicated in another e-mail to Jonathan, there's little to be gained from this restriction, but things to be lost, and hence we should continue with the practice of allowing the answerer to send with offered codecs not contained in the answer. -- Flemming > > This way we have implementations compatible with both rfc2543 and rfc2543bis3. It is a compromise that I think should always work. > > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. > 2107 Wilson Blvd., Suite 301 > Arlington, VA 22201 > PCN: 703-621-4040 for voice / fax > www.atelo.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 10:19:34 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 KAA07850 for ; Fri, 15 Feb 2002 10:19:34 -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 KAA25054; Fri, 15 Feb 2002 10:18: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 KAA25019 for ; Fri, 15 Feb 2002 10:18:17 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07792 for ; Fri, 15 Feb 2002 10:18:15 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FFIX6Y003357; Fri, 15 Feb 2002 10:18:35 -0500 (EST) Message-ID: <3C6D2699.C0625EFA@dynamicsoft.com> Date: Fri, 15 Feb 2002 10:17:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hiroshi Waki CC: mmusic@ietf.org Subject: Re: [MMUSIC] Answerers alternative selection of m lines(one IPv4 and the other IPv6) References: <14c501c1b603$45b6ce90$e10a3c81@pikmin> 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 Hiroshi Waki wrote: > > Hi all, > > Suppose the offerer is dual stack and does not know which version of > IP is supported by the answerer. The answerer may support both or > only one IP version, either v4 or v6. > > In this case, the offerer may use the offer that includes two m lines > (one IPv4 and the other IPv6) grouped using FID. Both lines contains > the same codec(s). What the offerer expects is that the answerer > selects only one of the two m lines, i.e. the answerer accepts > one m line with an appropriate port, and explicitly rejects > the other m line with port=0 in the corresponding m lines in the answer. > > However, the answerer may accept both of them, and if so, it means that > two RTP sessions at the same time, as the draft-ietf-mmusic-fid-05 says, > > 'Remember that if several "m" lines grouped together using FID semantics > > contain the same codec the media agent MUST send media over several > RTP sessions at the same time' in 7.4.1. > > How can the offerer prevent it? > Do we need a new mechanism to show "alternative" m lines to let > the answer know that it must select only one of them? You can always send an updated offer with the v4 stream disabled. In fact, you can avoid fid altogether, and send the offer with both v4 and v6, and once you get the answer, send an updated offer with just one of them immediately (if needed). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 12:24: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 MAA12422 for ; Fri, 15 Feb 2002 12:24: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 MAA04688; Fri, 15 Feb 2002 12:23:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA04643 for ; Fri, 15 Feb 2002 12:23:06 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12390 for ; Fri, 15 Feb 2002 12:23:02 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1FHMIN00552; Fri, 15 Feb 2002 11:22:18 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <17Q8CQQK>; Fri, 15 Feb 2002 11:22:18 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011878F4@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Flemming Andreasen'" , Jonathan Rosenberg Cc: Bert Culpepper , "'Roman Shpount'" , mmusic@ietf.org Subject: RE: [MMUSIC] Re: Using payload types not specified in answer in offer/answer Date: Fri, 15 Feb 2002 11:22:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B645.50E94CB0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B645.50E94CB0 Content-Type: text/plain; charset="iso-8859-1" Doesn't the new consensus mean that we're back to the original requirement that the client (offerer) needs to load multiple DSP's and be prepared to receive on any of them (at least until the second offer/answer is made)? Am I missing something? We should have a mechanism to avoid this for lesser clients that can only use one DSP resource at a time. What happened to the a=pickone attribute? Sanjoy > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Friday, February 15, 2002 9:03 AM > To: Jonathan Rosenberg > Cc: Bert Culpepper; 'Roman Shpount'; mmusic@ietf.org > Subject: Re: [MMUSIC] Re: Using payload types not specified > in answer in > offer/answer > > > > > Jonathan Rosenberg wrote: > > > Really, the offer/answer model has some attributes which are merely > > declarative (like ptime), and others which are shared and negotiated > > (directionality). Therefore, the argument that SDP is > always declarative > > holds no ground, since I think (hope) we can agree that > there are most > > definitely attributes which are shared and negotiated. So, > are, or are > > not, codecs part of this? If the goal, in general, is for a > common codec > > to be used in each direction, then I think the view has to > be that they > > are shared. While we could just reduce the set later with > an additional > > offer, as Flemming has pointed out, the value that the O/A exchange > > brings to the table is the ability to not need to do that. > > Actually, it doesn't. With the present O/A text, we already > have to support > all codecs in the offer until we get the answer. Furthermore, > since the > offerer has no control over the answer, it is quite possible > that the answer > contains more than one of the offered codec, and hence we are > back where we > started. The only way to get down to one codec is a new > offer/answer exchange. > Thus, the above can at most be seen as a possible optimization between > offerers and answerers that both agree to pick just one > codec. Since it > doesn't really solve the problem then, we loose some > functionality in the > process, and we depart with what at least a lot of people had > understood > (based on your earlier e-mail), we should stick to > yesterday's consensus. > > -- Flemming > > > > > > > > Thanks, > > Jonathan R. > > > > Bert Culpepper wrote: > > > > > > > > > > > Also note, that you can achieve almost the same by > issuing an updated > > > > offer/answer with the the single codec, if that's what you want. > > > > > > I shouldn't be in so much of a hurry to jump in...You're > right, with an > > > extra message exchange I can satisfy both goals. This > will work for me. > > > > > > Thanks, > > > Bert > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > ------_=_NextPart_001_01C1B645.50E94CB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] Re: Using payload types not specified in answer in = offer/answer

Doesn't the new consensus mean that we're back to the = original requirement that the client (offerer) needs to load multiple = DSP's and be prepared to receive on any of them (at least until the = second offer/answer is made)? Am I missing something? We should have a = mechanism to avoid this for lesser clients that can only use one DSP = resource at a time. What happened to the a=3Dpickone = attribute?

Sanjoy

> -----Original Message-----
> From: Flemming Andreasen [mailto:fandreas@cisco.com]=
> Sent: Friday, February 15, 2002 9:03 AM
> To: Jonathan Rosenberg
> Cc: Bert Culpepper; 'Roman Shpount'; = mmusic@ietf.org
> Subject: Re: [MMUSIC] Re: Using payload types = not specified
> in answer in
> offer/answer
>
>
>
>
> Jonathan Rosenberg wrote:
>
> > Really, the offer/answer model has some = attributes which are merely
> > declarative (like ptime), and others which = are shared and negotiated
> > (directionality). Therefore, the argument = that SDP is
> always declarative
> > holds no ground, since I think (hope) we = can agree that
> there are most
> > definitely attributes which are shared and = negotiated. So,
> are, or are
> > not, codecs part of this? If the goal, in = general, is for a
> common codec
> > to be used in each direction, then I think = the view has to
> be that they
> > are shared. While we could just reduce the = set later with
> an additional
> > offer, as Flemming has pointed out, the = value that the O/A exchange
> > brings to the table is the ability to not = need to do that.
>
> Actually, it doesn't. With the present O/A = text, we already
> have to support
> all codecs in the offer until we get the = answer. Furthermore,
> since the
> offerer has no control over the answer, it is = quite possible
> that the answer
> contains more than one of the offered codec, = and hence we are
> back where we
> started. The only way to get down to one codec = is a new
> offer/answer exchange.
> Thus, the above can at most be seen as a = possible optimization between
> offerers and answerers that both agree to pick = just one
> codec. Since it
> doesn't really solve the problem then, we loose = some
> functionality in the
> process, and we depart with what at least a lot = of people had
> understood
> (based on your earlier e-mail), we should stick = to
> yesterday's consensus.
>
> -- Flemming
>
>
> >
> >
> > Thanks,
> > Jonathan R.
> >
> > Bert Culpepper wrote:
> > >
> > > >
> > > > Also note, that you can achieve = almost the same by
> issuing an updated
> > > > offer/answer with the the single = codec, if that's what you want.
> > >
> > > I shouldn't be in so much of a hurry = to jump in...You're
> right, with an
> > > extra message exchange I can satisfy = both goals.  This
> will work for me.
> > >
> > > Thanks,
> > > Bert
> >
> > --
> > Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> > Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> > = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> > = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> > http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> > http://www.dynamicsoft.com
>
> --
> Flemming Andreasen
> Cisco Systems
>
>
>
> = _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

------_=_NextPart_001_01C1B645.50E94CB0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 12:52: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 MAA13904 for ; Fri, 15 Feb 2002 12:52: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 MAA06828; Fri, 15 Feb 2002 12:48:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA06783 for ; Fri, 15 Feb 2002 12:48:40 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13778 for ; Fri, 15 Feb 2002 12:48:38 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA09237; Fri, 15 Feb 2002 09:47:43 -0800 (PST) Message-ID: <3C6D49C9.DD75C57C@cisco.com> Date: Fri, 15 Feb 2002 12:47:53 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sanjoy Sen CC: Jonathan Rosenberg , Bert Culpepper , "'Roman Shpount'" , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <933FADF5E673D411B8A30002A5608A0E011878F4@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Sanjoy Sen wrote: > > > Doesn't the new consensus mean that we're back to the original > requirement that the client (offerer) needs to load multiple DSP's and > be prepared to receive on any of them (at least until the second > offer/answer is made)? Actually, we never departed from that. > Am I missing something? We should have a mechanism to avoid this for > lesser clients that can only use one DSP resource at a time. What > happened to the a=pickone attribute? There is basically no way of doing this in a backwards compatible way. You can come fairly close with the current text, additional offer/answer exchanges and/or new attributes, but at the end of the day, we can't change the way SDP works. The level of expressiveness you are looking for is provided by SDPng. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 13:18:34 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 NAA14693 for ; Fri, 15 Feb 2002 13:18:34 -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 NAA08588; Fri, 15 Feb 2002 13:17:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA08554 for ; Fri, 15 Feb 2002 13:17:31 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14600 for ; Fri, 15 Feb 2002 13:17:30 -0500 (EST) DATE: 15 Feb 2002 18:17:29 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 15 Feb 2002 18:17:30 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: , , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA08555 Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > I would definitely agree with Jonathan in his point of view about codec > negotiation if we had a luxury of defining a new standard. Unfortunately > what is being done here (at least from my point of view) is just an > attempt to ensure interoperability of existing applications. My > suggestion for this standard would be something along the lines: > > Offerer MUST accept all the codecs from the original offer. Answerer > SHOULD NOT send using any codecs not specified in the answer. > Flemming Andreasen wrote: > "SHOULD NOT" is not to be taken lightly, and hence this effectively says > that you can only use the codecs in the answer. As I indicated in > another e-mail to Jonathan, there's little to be gained from this > restriction, but things to be lost, and hence we should continue with > the practice of allowing the answerer to send with offered codecs not > contained in the answer. There are two problems that I have with answerers sending with codecs not in the answer: 1. Interoperability with original RFC2543 2. Interoperability with current 1 of N codecs selection Let me explain the second one. The offerer is capable of sending and receiving G.711, G.723 and telephone-events with only G.711 or G.723 supported at the same time. The answerer is capable of sending and receiving G.711 and G.723, but can only send telephone-event. The following message exchange takes place: Initial offer: v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 6400 RTP/AVP 0 4 110 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:110 telephone-events a=inactive Initial answer: v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 6400 RTP/AVP 0 4 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=inactive When Alice generates updated offer it has no way of knowing that Bob intends to use telephon d offer: v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.example.com t=0 0 m=audio 6400 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv Final answer: v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 6400 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv Thus after this exchange telephone-events are not used by either party. Thus I am not sure that we achieve anything by allowing the answerer to send with payloads not included in the answer. The solution for the problems that we are trying to solve (assymetric use of codecs) is in either SDPng or expanding SDP. I am convinced that expanding SDP can be done in backwards-compatible way (for instance by adding a direction attribute on the per codec basis), but the discussion of this is probably outside the topic of this thread. ____________________________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 13:35: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 NAA15037 for ; Fri, 15 Feb 2002 13:35: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 NAA09741; Fri, 15 Feb 2002 13:35:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09708 for ; Fri, 15 Feb 2002 13:35:07 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15029 for ; Fri, 15 Feb 2002 13:35:06 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FIZ96Y003586; Fri, 15 Feb 2002 13:35:09 -0500 (EST) Message-ID: <3C6D54AD.1BE173E6@dynamicsoft.com> Date: Fri, 15 Feb 2002 13:34:21 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Flemming Andreasen CC: Sanjoy Sen , Bert Culpepper , "'Roman Shpount'" , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer References: <3C6D49C9.DD75C57C@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > > > Am I missing something? We should have a mechanism to avoid this for > > lesser clients that can only use one DSP resource at a time. What > > happened to the a=pickone attribute? > > There is basically no way of doing this in a backwards compatible way. > You can come fairly close with the current text, additional offer/answer > exchanges and/or new attributes, but at the end of the day, we can't > change the way SDP works. The level of expressiveness you are looking > for is provided by SDPng. Or, with another O/A exchange to reduce to a single codec. The a=pickone never went forward, that is not the issue here as Flemming indicates. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 14:21: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 OAA16482 for ; Fri, 15 Feb 2002 14:21:47 -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 OAA11415; Fri, 15 Feb 2002 14:10: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 OAA11381 for ; Fri, 15 Feb 2002 14:10:41 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16072 for ; Fri, 15 Feb 2002 14:10:39 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10296; Fri, 15 Feb 2002 11:09:53 -0800 (PST) Message-ID: <3C6D5D0D.D0B5E414@cisco.com> Date: Fri, 15 Feb 2002 14:10:05 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: jdrosen@dynamicsoft.com, bert.culpepper@intervoice-brite.com, mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > Roman Shpount wrote: > > > I would definitely agree with Jonathan in his point of view about codec > > negotiation if we had a luxury of defining a new standard. Unfortunately > > what is being done here (at least from my point of view) is just an > > attempt to ensure interoperability of existing applications. My > > suggestion for this standard would be something along the lines: > > > > Offerer MUST accept all the codecs from the original offer. Answerer > > SHOULD NOT send using any codecs not specified in the answer. > > > > Flemming Andreasen wrote: > > > "SHOULD NOT" is not to be taken lightly, and hence this effectively says > > that you can only use the codecs in the answer. As I indicated in > > another e-mail to Jonathan, there's little to be gained from this > > restriction, but things to be lost, and hence we should continue with > > the practice of allowing the answerer to send with offered codecs not > > contained in the answer. > > There are two problems that I have with answerers sending with codecs not in the answer: > 1. Interoperability with original RFC2543 Not sure this is a real issue, as RFC 2543 was not entirely clear on this and, as indicated earlier, the understanding a lot of people had is to allow the answerer to send with any offered codec, regardless of the answer. > > 2. Interoperability with current 1 of N codecs selection > > Let me explain the second one. The offerer is capable of sending and receiving G.711, G.723 and telephone-events with only G.711 or G.723 supported at the same time. The answerer is capable of sending and receiving G.711 and G.723, but can only send telephone-event. The following message exchange takes place: > > Initial offer: > > v=0 > o=alice 2890844526 2890844526 IN IP4 host.anywhere.com > s= > c=IN IP4 host.anywhere.com > t=0 0 > m=audio 6400 RTP/AVP 0 4 110 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:110 telephone-events > a=inactive > > Initial answer: > > v=0 > o=bob 2890844730 2890844731 IN IP4 host.example.com > s= > c=IN IP4 host.example.com > t=0 0 > m=audio 6400 RTP/AVP 0 4 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > a=inactive > > When Alice generates updated offer it has no way of knowing that Bob intends to use telephone-events, so it does not include it in updated offer: > > v=0 > o=alice 2890844526 2890844527 IN IP4 host.anywhere.com > s= > c=IN IP4 host.example.com > t=0 0 > m=audio 6400 RTP/AVP 4 > a=rtpmap:4 G723/8000 > a=sendrecv > > Final answer: > > v=0 > o=bob 2890844730 2890844732 IN IP4 host.example.com > s= > c=IN IP4 host.example.com > t=0 0 > m=audio 6400 RTP/AVP 4 > a=rtpmap:4 G723/8000 > a=sendrecv > > Thus after this exchange telephone-events are not used by either party. Thus I am not sure that we achieve anything by allowing the answerer to send with payloads not included in the answer. Well, nothing prevents Alice from including telephone-events in the offer again, especially if she knows that Bob could actually still use it, so this really doesn't show much. Also, if you didn't use the "inactive" offer/answer intially, but instead did "sendrecv", it would still work. > > The solution for the problems that we are trying to solve (assymetric use of codecs) I'm not trying to solve that problem, as it would entail much more than we have on the table here. The question is simply which of two interpretations/modes of operation to go with. I've provided arguments on this in several e-mails already. > is in either SDPng or expanding SDP. I am convinced that expanding SDP can be done in backwards-compatible way (for instance by adding a direction attribute on the per codec basis), but the discussion of this is probably outside the topic of this thread. I agree it's a separate discussion :-) -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 14:58: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 OAA17985 for ; Fri, 15 Feb 2002 14:58: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 OAA13584; Fri, 15 Feb 2002 14:51:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA13555 for ; Fri, 15 Feb 2002 14:51:46 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17800 for ; Fri, 15 Feb 2002 14:51:44 -0500 (EST) SUBJECT: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer DATE: 15 Feb 2002 19:51:44 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 15 Feb 2002 19:51:45 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: , , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA13556 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 Roman Shpount wrote: > There are two problems that I have with answerers sending with codecs > not in the answer: > 1. Interoperability with original RFC2543 Flemming Andreasen wrote: > Not sure this is a real issue, as RFC 2543 was not entirely clear on > this and, as indicated earlier, the understanding a lot of people had is > to allow the answerer to send with any offered codec, regardless of the > answer. The problem is that there are also enough people that interpreted RFC 2543 the other way (not accepting codecs not specified in the answer). So, in order to interoperate with products from those people the answerer should not send media with codecs not included in the answer. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 16:00: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 QAA19414 for ; Fri, 15 Feb 2002 16:00: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 PAA16922; Fri, 15 Feb 2002 15:59: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 PAA16887 for ; Fri, 15 Feb 2002 15:59:08 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19379 for ; Fri, 15 Feb 2002 15:59:06 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA18275; Fri, 15 Feb 2002 12:58:17 -0800 (PST) Message-ID: <3C6D7675.84792351@cisco.com> Date: Fri, 15 Feb 2002 15:58:29 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: jdrosen@dynamicsoft.com, bert.culpepper@intervoice-brite.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > Roman Shpount wrote: > > > There are two problems that I have with answerers sending with codecs > > not in the answer: > > 1. Interoperability with original RFC2543 > > Flemming Andreasen wrote: > > > Not sure this is a real issue, as RFC 2543 was not entirely clear on > > this and, as indicated earlier, the understanding a lot of people had is > > to allow the answerer to send with any offered codec, regardless of the > > answer. > > The problem is that there are also enough people that interpreted RFC 2543 the other way (not accepting codecs not specified in the answer). So, in order to interoperate with products from those people the answerer should not send media with codecs not included in the answer. We obviously can't support both interpretations, however could we put in a note about it being a potential problem for some older implementations and hence at least alert people to it ? -- Flemming > > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. > 2107 Wilson Blvd., Suite 301 > Arlington, VA 22201 > PCN: 703-621-4040 for voice / fax > www.atelo.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 16:26: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 QAA20047 for ; Fri, 15 Feb 2002 16:26: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 QAA18534; Fri, 15 Feb 2002 16:25: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 QAA18497 for ; Fri, 15 Feb 2002 16:25:25 -0500 (EST) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20026 for ; Fri, 15 Feb 2002 16:25:23 -0500 (EST) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id PAA02245 for ; Fri, 15 Feb 2002 15:28:39 -0600 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 15 Feb 2002 15:08:48 -0600 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Fri, 15 Feb 2002 15:24:46 -0600 From: "Bert Culpepper" To: "'Flemming Andreasen'" , "'Roman Shpount'" Cc: , Subject: RE: [MMUSIC] Re: Using payload types not specified in answer in offer/answer Date: Fri, 15 Feb 2002 16:24:36 -0500 Message-ID: <005c01c1b667$2bd4af10$7397d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3C6D7675.84792351@cisco.com> Importance: Normal 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 Flemming Andreasen wrote: > > Roman Shpount wrote: > > > Roman Shpount wrote: > > > > > There are two problems that I have with answerers sending > with codecs > > > not in the answer: > > > 1. Interoperability with original RFC2543 > > > > Flemming Andreasen wrote: > > > > > Not sure this is a real issue, as RFC 2543 was not > entirely clear on > > > this and, as indicated earlier, the understanding a lot > of people had is > > > to allow the answerer to send with any offered codec, > regardless of the > > > answer. > > > > The problem is that there are also enough people that > interpreted RFC 2543 the other way (not accepting codecs not > specified in the answer). So, in order to interoperate with > products from those people the answerer should not send media > with codecs not included in the answer. I had the same understanding as Flemming describes (it solves clipping issues and supports sending early media). However, as I said earlier I'd rather see positive indications of what a sender will send (this doesn't affect clipping/early media capabilities). But again, this is not what I got from reading rfc2543 and rfc2327. I think the interpretation you describe is incorrect (although I'd prefer your interpretation). > > We obviously can't support both interpretations, however > could we put in a note about it being a potential problem for > some older implementations and hence at least alert people to it ? > I'd like to see some mention of it written down someplace. That way I wouldn't have to argue my interpretation, I could point to a I-D/rfc :) Regards, Bert > -- Flemming > > > > > > ___________________________________ > > Roman Shpount, VP of Technology > > aTelo, Inc. > > 2107 Wilson Blvd., Suite 301 > > Arlington, VA 22201 > > PCN: 703-621-4040 for voice / fax > > www.atelo.com > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > 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 Feb 15 16: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 QAA20272 for ; Fri, 15 Feb 2002 16: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 QAA19354; Fri, 15 Feb 2002 16:32: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 QAA19283 for ; Fri, 15 Feb 2002 16:32:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20261 for ; Fri, 15 Feb 2002 16:32:12 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1FLWU6Y003931 for ; Fri, 15 Feb 2002 16:32:31 -0500 (EST) Message-ID: <3C6D7E3D.4A18EC33@dynamicsoft.com> Date: Fri, 15 Feb 2002 16:31:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] summarizing discussion on codec placement in answer 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 Folks, I wanted to take a moment to summarize where we were in regards to our long thread on interpretation of the codecs in the answer. The purpose of the summarization is to put all the points on the table, and hopefully invite some further comment from folks outside the few thread participants in the few days which remain. ISSUE: A sends an offer to B. That offer, for example, is for a single sendrecv media stream, which lists codecs 1,2 and 3. The answerer, B, responds, and lists codecs 1 and 2. Now, the question is this: can B still send to A using codec 3? Related to that, can B add codecs in the answer, which A can then send with? Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Arguments for NO: 1. The purpose of the O/A model is to agree on shared views of certain session parameters, such as the directionality (send/recv/sendrecv). Codecs fit into that category as well, since you are already required to indicate, in the answer, a set that partially overlaps with the offer. Furthermore, the goal with codecs is to have the same in both directions, generally, so that this would speak to them being a shared state that is negotiated. 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If you go for YES, there may be interop issues. The converse is not true, of course. 3. It is very useful to narrow down the codec sets in the answer, and we should not always require an extra exchange of O/A just to do that. I took a private poll amongst some implementors. The initial results showed that most assumed the YES case. Some more mails since then indicate its a bit more split, although I think somewhat in favor of YES still. I am somewhat on the fence; I think NO is more correct based on offer/answer, although YES would be the SDP purist view. What I really want is more opinions on this one.... THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 16:42:05 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 QAA20508 for ; Fri, 15 Feb 2002 16:42:05 -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 QAA19756; Fri, 15 Feb 2002 16:40:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19718 for ; Fri, 15 Feb 2002 16:40:28 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20429 for ; Fri, 15 Feb 2002 16:40:26 -0500 (EST) SUBJECT: Re: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer DATE: 15 Feb 2002 21:40:28 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 15 Feb 2002 21:40:28 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: , , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA19719 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 Roman Shpount wrote: > There are two problems that I have with answerers sending with codecs > not in the answer: > 1. Interoperability with original RFC2543 Flemming Andreasen wrote: > Not sure this is a real issue, as RFC 2543 was not entirely clear on > this and, as indicated earlier, the understanding a lot of people had is > to allow the answerer to send with any offered codec, regardless of the > answer. Roman Shpount wrote: > The problem is that there are also enough people that interpreted RFC > 2543 the other way (not accepting codecs not specified in the answer). > So, in order to interoperate with products from those people the > answerer should not send media with codecs not included in the answer. Flemming Andreasen wrote: > We obviously can't support both interpretations, however could we put in > a note about it being a potential problem for some older implementations > and hence at least alert people to it ? Why can't we? If a device accepts everything in its offer and sends only with codecs specified in the answer it will interoperate with devices that are implemented according to either interpretation. This is a general "accept as much as possible, generate only standard compliant" type principal. This is why I proposed "SHOULD NOT send with codecs not specified in answer" in the standard. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 16:54: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 QAA20897 for ; Fri, 15 Feb 2002 16:54: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 QAA20471; Fri, 15 Feb 2002 16:53:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20440 for ; Fri, 15 Feb 2002 16:53:51 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20888 for ; Fri, 15 Feb 2002 16:53:50 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA19811; Fri, 15 Feb 2002 13:53:08 -0800 (PST) Message-ID: <3C6D834B.C06B6E7F@cisco.com> Date: Fri, 15 Feb 2002 16:53:15 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: jdrosen@dynamicsoft.com, bert.culpepper@intervoice-brite.com, mmusic@ietf.org Subject: Re: [MMUSIC] Re: Using payload types not specified in answer in offer/answer 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 Roman Shpount wrote: > > Flemming Andreasen wrote: > > > We obviously can't support both interpretations, however could we put in > > a note about it being a potential problem for some older implementations > > and hence at least alert people to it ? > > Why can't we? If a device accepts everything in its offer and sends only with codecs specified in the answer it will interoperate with devices that are implemented according to either interpretation. This is a general "accept as much as possible, generate only standard compliant" type principal. This is why I proposed "SHOULD NOT send with codecs not specified in answer" in the standard. Well, that would be picking one interpretation - not supporting both. -- Flemming > > ___________________________________ > Roman Shpount, VP of Technology > aTelo, Inc. > 2107 Wilson Blvd., Suite 301 > Arlington, VA 22201 > PCN: 703-621-4040 for voice / fax > www.atelo.com -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 16:59: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 QAA21057 for ; Fri, 15 Feb 2002 16:59: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 QAA20636; Fri, 15 Feb 2002 16:58:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20601 for ; Fri, 15 Feb 2002 16:58:30 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21050 for ; Fri, 15 Feb 2002 16:58:28 -0500 (EST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA22637; Fri, 15 Feb 2002 13:57:43 -0800 (PST) Message-ID: <3C6D8460.7F9D423C@cisco.com> Date: Fri, 15 Feb 2002 16:57:52 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: mmusic@ietf.org Subject: Re: [MMUSIC] summarizing discussion on codec placement in answer References: <3C6D7E3D.4A18EC33@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If > you go for YES, there may be interop issues. The converse is not true, > of course. On the contrary. Consider the offerer sending codec 1, 2, 3 based on the "NO" interpretation, and the answerer sending back codec 1, 2 based on the "YES" interpretation. Regardless of which interpretation you pick, you can get into trouble when trying to interoperate with the other. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 17:29: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 RAA21851 for ; Fri, 15 Feb 2002 17:29:37 -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 RAA22656; Fri, 15 Feb 2002 17:28: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 RAA22623 for ; Fri, 15 Feb 2002 17:28:27 -0500 (EST) Received: from mail2.intervoice-brite.com (mail2.intervoice-brite.com [204.62.8.15]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21800 for ; Fri, 15 Feb 2002 17:28:24 -0500 (EST) Received: from DALNTMS02.ivbi.com (dalntms02.ivbi.com [151.214.90.44]) by mail2.intervoice-brite.com (Build 101 8.9.3/NT-8.9.3) with ESMTP id QAA02562 for ; Fri, 15 Feb 2002 16:31:40 -0600 Received: from 172.16.16.64 (unverified) by DALNTMS02.ivbi.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Fri, 15 Feb 2002 16:11:49 -0600 Received: from bculpepperpc ([151.214.151.115]) by 172.16.16.64; Fri, 15 Feb 2002 16:27:51 -0600 From: "Bert Culpepper" To: "'Jonathan Rosenberg'" , Subject: RE: [MMUSIC] summarizing discussion on codec placement in answer Date: Fri, 15 Feb 2002 17:27:42 -0500 Message-ID: <005e01c1b66f$fc8f7650$7397d697@bculpepperpc> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <3C6D7E3D.4A18EC33@dynamicsoft.com> Importance: Normal 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 I think your YES points are currently allowed by rfc2543 and rfc2327. However, I'd like the changes as suggested by your NO points. But I see these as changes and likely to require changes in some implementations. (Again, I'd like to deprecate sending codecs not "declared" by the sender.) Regards, Bert > -----Original Message----- > From: mmusic-admin@ietf.org [mailto:mmusic-admin@ietf.org]On Behalf Of > Jonathan Rosenberg > Sent: Friday, February 15, 2002 4:32 PM > To: mmusic@ietf.org > Subject: [MMUSIC] summarizing discussion on codec placement in answer > > > Folks, > > I wanted to take a moment to summarize where we were in regards to our > long thread on interpretation of the codecs in the answer. The purpose > of the summarization is to put all the points on the table, and > hopefully invite some further comment from folks outside the > few thread > participants in the few days which remain. > > ISSUE: > > A sends an offer to B. That offer, for example, is for a > single sendrecv > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > and lists codecs 1 and 2. Now, the question is this: can B > still send to > A using codec 3? > Related to that, can B add codecs in the > answer, which > A can then send with? > > Arguments for YES: > > 1. A needs to be prepared to receive with codec 3 once it sends the > offer anyway. > 2. If A wants to restrict the set based on the answer, it can always > generate a new offer with a reduced set of codecs. > 3. SDP has always been interpreted as indicating your own > capabilities, > and is therefore an "advertisement" that sticks until updated. > 4. There are useful cases for adding codecs in the answer, > particularly, > support for rfc2833. Thus, lets say A is an end user which > can send rfc > 2833, but not receive it. So, when it sends an INVITE, it doesn't > include rfc2833 in the INVITE. The server that responds is a media > server, which supports rfc2833. So, it includes it in the > answer. Now, A > can actually send with it during the middle of the session, > and it will > never receive it (since it didn't advertise it). This > provides a useful > function that would otherwise require FID. > > Arguments for NO: > > 1. The purpose of the O/A model is to agree on shared views of certain > session parameters, such as the directionality (send/recv/sendrecv). > Codecs fit into that category as well, since you are already > required to > indicate, in the answer, a set that partially overlaps with the offer. > Furthermore, the goal with codecs is to have the same in both > directions, generally, so that this would speak to them being a shared > state that is negotiated. > > 2. Many people have interpreted the SDP/bis/rfc2543 drafts > this way. If > you go for YES, there may be interop issues. The converse is not true, > of course. > > 3. It is very useful to narrow down the codec sets in the > answer, and we > should not always require an extra exchange of O/A just to do that. > > > > I took a private poll amongst some implementors. The initial results > showed that most assumed the YES case. Some more mails since then > indicate its a bit more split, although I think somewhat in > favor of YES > still. > > I am somewhat on the fence; I think NO is more correct based on > offer/answer, although YES would be the SDP purist view. What I really > want is more opinions on this one.... > > THanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 19:57: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 TAA24036 for ; Fri, 15 Feb 2002 19:57:54 -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 TAA27806; Fri, 15 Feb 2002 19:56:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA27774 for ; Fri, 15 Feb 2002 19:56:07 -0500 (EST) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24016 for ; Fri, 15 Feb 2002 19:56:05 -0500 (EST) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/31/02) with ESMTP id JAA00573 for ; Sat, 16 Feb 2002 09:56:05 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp by vcs3.rdh.ecl.ntt.co.jp (8.9.3/3.7W/20020131) with ESMTP id JAA00113 for ; Sat, 16 Feb 2002 09:56:04 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from eclscan3.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/02/13/02) with ESMTP id JAA19439 for ; Sat, 16 Feb 2002 09:56:03 +0900 (JST) (envelope-from ohba.takumi@lab.ntt.co.jp) Received: from imi.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id JAA05826 for ; Sat, 16 Feb 2002 09:56:03 +0900 (JST) Received: from ohbamebius by imi.m.ecl.ntt.co.jp (8.9.3/3.7W) with SMTP id JAA29206 for ; Sat, 16 Feb 2002 09:56:01 +0900 (JST) Reply-To: ohba.takumi@lab.ntt.co.jp Message-Id: <4.0.1-J.20020216095921.00e30ac0@imi.m.ecl.ntt.co.jp> X-Sender: ohba.takumi@lab.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1-J Date: Sat, 16 Feb 2002 10:20:18 +0900 To: mmusic@ietf.org From: Takumi Ohba Subject: Re: [MMUSIC] Answerers alternative selection of m lines(one IPv4 and the other IPv6) In-Reply-To: <3C6D2699.C0625EFA@dynamicsoft.com> References: <14c501c1b603$45b6ce90$e10a3c81@pikmin> 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, At 10:17 02/02/15 -0500, Jonathan Rosenberg wrote: > You can always send an updated offer with the v4 stream disabled. In > fact, you can avoid fid altogether, and send the offer with both v4 and > v6, and once you get the answer, send an updated offer with just one of > them immediately (if needed). Establishing two RTP sessions is not the offerer's initial intention. Sending an updated offer will cause increasing setup delay of the call that matches to the offerer's intention. In addition, I'm not sure that all implementations of dual stack can handle both V4 and V6 at one time. Is there a mechanism that has been already discussed in this WG and be able to show the offerer's intention for the answerer to select only one of multi ple (or at least two) choices? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 15 22:25: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 WAA26806 for ; Fri, 15 Feb 2002 22:25: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 WAA03083; Fri, 15 Feb 2002 22:24: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 WAA03048 for ; Fri, 15 Feb 2002 22:24:47 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26788 for ; Fri, 15 Feb 2002 22:24:44 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.69]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1G3P36Y004380; Fri, 15 Feb 2002 22:25:04 -0500 (EST) Message-ID: <3C6DD0DE.EDE98426@dynamicsoft.com> Date: Fri, 15 Feb 2002 22:24:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ohba.takumi@lab.ntt.co.jp CC: mmusic@ietf.org Subject: Re: [MMUSIC] Answerers alternative selection of m lines(one IPv4 and the other IPv6) References: <4.0.1-J.20020216095921.00e30ac0@imi.m.ecl.ntt.co.jp> 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 Takumi Ohba wrote: > > Hi, > > At 10:17 02/02/15 -0500, Jonathan Rosenberg wrote: > > You can always send an updated offer with the v4 stream disabled. In > > fact, you can avoid fid altogether, and send the offer with both v4 > and > > v6, and once you get the answer, send an updated offer with just one > of > > them immediately (if needed). > > Establishing two RTP sessions is not the offerer's initial intention. > Sending an updated offer will cause increasing setup delay of the call > that > matches to the offerer's intention. No; the call can proceed while the second pass occurs. I agree its not ideal, but a lot of problems can be solved by multi-pass offer-answers if needed. > In addition, I'm not sure that all implementations of dual stack can > handle > both V4 and V6 at one time. There is no need to actually support both at the same time, only two advertise two of them, and then pick one once the answer comes. > > Is there a mechanism that has been already discussed in this WG and be > able > to show the offerer's intention for the answerer to select only one of > multi > ple (or at least two) choices? Not that I am aware of. Doesn't mean its not a good idea; we've discussed this kind of thing in the context of nat, where a caller can use stun to obtain a public address. THen, it sends its invite with both the public and private addresses, and wants the callee to pick just one. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 01:15: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 BAA19275 for ; Mon, 18 Feb 2002 01:15:00 -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 BAA28356; Mon, 18 Feb 2002 01:13:04 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28309 for ; Mon, 18 Feb 2002 01:13:02 -0500 (EST) Received: from yourwebsite.com (adsl-208-189-133-219.dsl.hstntx.swbell.net [208.189.133.219]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19259 for ; Mon, 18 Feb 2002 01:12:59 -0500 (EST) From: WC-4128@myhealthyamericacard.com Message-Id: <200202180612.BAA19259@ietf.org> Reply-To: WC-4128@myhealthyamericacard.com To: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Mon, 18 Feb 2002 00:16:09 -0600 Subject: [MMUSIC] (no subject) 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 Medical
 
Medical Problems?
Pre-Existing Medical Conditions?
Smoker?
Overweight?
Can't Qualify For Health Insurance?
Lost Your Job?
Do You Need Immediate Coverage?
 
Can You Afford $50.00 Per Month To Get No Out-Of-Pocket Family Coverage from the best PPO medical provider based discount services in the country? 

Click Here To Check It Out

Note: This e-mail is a one-time advertisement for an affordable PPO like health program sent from the source provider. It is not a bulk mail advertising program and is only being sent once. There is no need to remove this from any mailing list.  

 

The HealthyAmericaCard - The Next Best Thing To Insurance
_______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 04:17: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 EAA28972 for ; Mon, 18 Feb 2002 04:17:28 -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 EAA08881; Mon, 18 Feb 2002 04:17:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA08848 for ; Mon, 18 Feb 2002 04:17:04 -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 EAA28963 for ; Mon, 18 Feb 2002 04:16:59 -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 g1I9GTtC001343 for ; Mon, 18 Feb 2002 01:16:29 -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 g1I9GTMa000547 for ; Mon, 18 Feb 2002 01:16:29 -0800 Date: Mon, 18 Feb 2002 01:11:20 -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: Agenda for Feb 20 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 Hi all, Here's the agenda for this Wednesday, 9AM PST (-8 GMT): http://rtsp.org/2002/telecon/agenda20Feb.html It's also available below. Rob Rtsp Tc Agenda20 Feb2002 _________________________________________________________________ 1. [1]Last Telecon 1. [2]Review Action Items/New Issues 2. [3]Resolved last telecon [4]This Telecon Last Telecon Minutes: [5]http://rtsp.org/2002/telecon/minutes06Feb.html Review Action Items/New Issues * ACTION ITEM (RL/HS): Submit new draft of RTSP before February 22 deadline * ACTION ITEM: Call for authors on MUTE proposed. AN is tentatively signed up Resolved last telecon * [6]http://rtsp.org/bug477423 - Unclearities regarding pause with range + RESOLVED: go with Magnus's proposal (see [7]Magnus' proposal) * [8]http://rtsp.org/bug518997 - Mixing Aggregate aand Non-aggregate Control + see [9]the email thread + Point a) RESOLVED + First point b) RESOLVED + Second point b) MUTE and UNMUTE o RESOLVED: separate draft + Point C) (same as [10]http://rtsp.org/bug477400) o RESOLVED: PING writeup will be done as part of next RTSP draft...continue discussion on mailing list o RESOLVED: deprecate PLAY w/o range as ping method This Telecon We'll try to slog through the issues from last time around. We've got two big, interrelated topics, for which there are a series of subissues. I'd like to come to some sort of consensus on the two issues * Mixing Aggregate and Non-aggregate Control - see [11]the email thread. This is related to several bugs: + [12]http://rtsp.org/bug477428 - Priorites between aggregated & non cntrl + [13]http://rtsp.org/bug483356 - media URL in Play on aggregated session + [14]http://rtsp.org/bug493270 - PAUSE/Play on single media in aggregate + [15]http://rtsp.org/bug506412 - RTSP Teardown functionallity * Eliminate queued play - see [16]the email thread and [17]http://rtsp.org/bug508211 . This relates to several issues + [18]http://rtsp.org/bug477424 - How to queue timed plays? + [19]http://rtsp.org/bug477432 - RTP info and queued plays + [20]http://rtsp.org/bug493265 - Pause - Play behaviour clarification + [21]http://rtsp.org/bug507882 - RTP timestamps when playing after pause References 1. http://rtsp.org/2002/telecon/agenda20Feb.html?template=plain#line3 2. http://rtsp.org/2002/telecon/agenda20Feb.html?template=plain#line7 3. http://rtsp.org/2002/telecon/agenda20Feb.html?template=plain#line12 4. http://rtsp.org/2002/telecon/agenda20Feb.html?template=plain#line26 5. http://rtsp.org/2002/telecon/minutes06Feb.html 6. http://rtsp.org/bug477423 7. http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00148.html 8. http://rtsp.org/bug518997 9. http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00115.html 10. http://rtsp.org/bug477400 11. http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00115.html 12. http://rtsp.org/bug477428 13. http://rtsp.org/bug483356 14. http://rtsp.org/bug493270 15. http://rtsp.org/bug506412 16. http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00105.html 17. http://rtsp.org/bug508211 18. http://rtsp.org/bug477424 19. http://rtsp.org/bug477432 20. http://rtsp.org/bug493265 21. http://rtsp.org/bug507882 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 11:13: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 LAA06689 for ; Mon, 18 Feb 2002 11:13:00 -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 LAA27210; Mon, 18 Feb 2002 11:11: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 LAA27181 for ; Mon, 18 Feb 2002 11:11:27 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06450; Mon, 18 Feb 2002 11:11:22 -0500 (EST) Message-Id: <200202181611.LAA06450@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 18 Feb 2002 11:11:22 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-ipv6-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 : Support for IPv6 in SDP Author(s) : S. Olson Filename : draft-ietf-mmusic-sdp-ipv6-02.txt Pages : 5 Date : 15-Feb-02 This document describes the use of IPv6 addresses [1] in conjunction with the Session Description Protocol (SDP) [2]. Specifically, this document clarifies existing text in SDP with regards to the syntax of IPv6 addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-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-ipv6-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-ipv6-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: <20020215100815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-ipv6-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-ipv6-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020215100815.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 Feb 18 17:03:32 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 RAA20194 for ; Mon, 18 Feb 2002 17:03:32 -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 RAA15403; Mon, 18 Feb 2002 17:02:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA15372 for ; Mon, 18 Feb 2002 17:02:24 -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 RAA20165 for ; Mon, 18 Feb 2002 17:02:19 -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 g1IM1jtC008190 for ; Mon, 18 Feb 2002 14:01:45 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g1IM1sMa021614 for ; Mon, 18 Feb 2002 14:01:54 -0800 Date: Mon, 18 Feb 2002 14:01:54 -0800 (Pacific Standard Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; boundary=NextPart Content-ID: Subject: [MMUSIC] RADPLAY extentions for SDP 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; charset=US-ASCII Content-ID: Hi all, Just wanted to let everyone know about a new draft defining extensions to SDP which help out in the process of RTP archiving, delivery and playback. Here's the abstract: This document defines RTP Archiving, Delivery, and Playback (RADPLAY) extensions for the Session Description Protocol (SDP, [RFC 2327]). These extensions provide a standard means of archiving and delivering RTP streams via HTTP, using SDP and the commonly used 'rtpdump' file format. As a result of its design, it also provides a way of delivering generic RTP streams over HTTP, thus making it a suitable replacement for approaches which rely on network-unfriendly mechanisms such as 'HTTP tunneling'. Give it a look, and lemme know what you think. I'd like to consider this as a submission to move down the standards track, so if people generally think this is a good idea, then we can work out what the strategy is for moving this work forward. Thanks Rob ---------- Forwarded message ---------- Date: Mon, 18 Feb 2002 11:10:46 -0500 From: "Internet-Drafts@ietf.org" To: IETF-Announce: ; Subject: I-D ACTION:draft-lanphier-radplay-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : RTP Archiving, Delivery, and Playback (RADPLAY) Extensions for SDP Author(s) : R. Lanphier Filename : draft-lanphier-radplay-00.txt Pages : 10 Date : 15-Feb-02 This document defines RTP Archiving, Delivery, and Playback (RADPLAY) extensions for the Session Description Protocol (SDP, [RFC 2327]). These extensions provide a standard means of archiving and delivering RTP streams via HTTP, using SDP and the commonly used 'rtpdump' file format. As a result of its design, it also provides a way of delivering generic RTP streams over HTTP, thus making it a suitable replacement for approaches which rely on network-unfriendly mechanisms such as 'HTTP tunneling'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lanphier-radplay-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-lanphier-radplay-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-lanphier-radplay-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 Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; access-type=mail-server; server="mailserv@ietf.org" Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; name="draft-lanphier-radplay-00.txt"; site="ftp.ietf.org"; access-type=anon-ftp; directory=internet-drafts Content-ID: Content-Transfer-Encoding: QUOTED-PRINTABLE --OtherAccess-- --NextPart-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 17:24: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 RAA20915 for ; Mon, 18 Feb 2002 17:24: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 RAA16100; Mon, 18 Feb 2002 17:24: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 RAA16060 for ; Mon, 18 Feb 2002 17:24:11 -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 RAA20909 for ; Mon, 18 Feb 2002 17:24:04 -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 g1IMNUtC012060 for ; Mon, 18 Feb 2002 14:23:30 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g1IMNeMa007293 for ; Mon, 18 Feb 2002 14:23:40 -0800 Date: Mon, 18 Feb 2002 14:23:39 -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] RADPLAY comment ... (fwd) 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 Forwarded with permission from the author.... ---------- Forwarded message ---------- Date: Mon, 18 Feb 2002 13:43:20 -0800 From: John Lazzaro To: "robla@real.com" Subject: RADPLAY comment ... Hi Rob, Quick comment on RADPLAY -- I think of all of those bits devoted to resiliency inside of each payload type (not via one of the generic resiliency schemes like RFC2733, but the extra codec-specific stuff that's added for resilience), all going to waste when downloaded via HTTP via TCP. I guess the packetization I'm working on is extreme in the regard: http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-00.txt where there's two versions (resilient and non-resilient) with a large relative bandwidth cost for resiliency (absolute cost isn't bad, though, about voice codec range). Maybe this would all be "outside" RADPLAY -- people would be expected to convert formats from resilient to non-resilient to optimize bandwidth as part of the file preparation process -- but maybe there's a reason why RADPLAY needs to be aware of the issue too ... --john lazzaro ------------------------------------------------------------------------- John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro ------------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 18:16: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 SAA22666 for ; Mon, 18 Feb 2002 18:16:08 -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 SAA18971; Mon, 18 Feb 2002 18:15:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA18940 for ; Mon, 18 Feb 2002 18:15:45 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22649 for ; Mon, 18 Feb 2002 18:15:40 -0500 (EST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1INF6I17562; Mon, 18 Feb 2002 17:15:07 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Feb 2002 17:15:06 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01187910@zrc2c012.us.nortel.com> From: "Sanjoy Sen" To: "'Jonathan Rosenberg'" , mmusic@ietf.org Subject: RE: [MMUSIC] summarizing discussion on codec placement in answer Date: Mon, 18 Feb 2002 17:15:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B8D2.18C967E0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B8D2.18C967E0 Content-Type: text/plain; charset="iso-8859-1" Jonathan, We at Nortel (that includes at least four of us including a codec expert) support the second option, i.e., "NO". The primary reason is the #3 reason that you've - we would like to have the possibility of narrowing down to one codec without the overhead of an extra roundtrip (O/A exchange). Also, its not clear to some of us how would you negotiate the attributes that're associated with the media session (e.g., security parameters). Example, suppose Offerer sends 3 codecs - 2,3,4 and the answerer responds with 3,4 and adds an a=keymgmt-data: attribute for this media, should the offerer be ready to accept 2 with the security keys applied? Thanks, Sanjoy > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, February 15, 2002 3:32 PM > To: mmusic@ietf.org > Subject: [MMUSIC] summarizing discussion on codec placement in answer > > > Folks, > > I wanted to take a moment to summarize where we were in regards to our > long thread on interpretation of the codecs in the answer. The purpose > of the summarization is to put all the points on the table, and > hopefully invite some further comment from folks outside the > few thread > participants in the few days which remain. > > ISSUE: > > A sends an offer to B. That offer, for example, is for a > single sendrecv > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > and lists codecs 1 and 2. Now, the question is this: can B > still send to > A using codec 3? Related to that, can B add codecs in the > answer, which > A can then send with? > > Arguments for YES: > > 1. A needs to be prepared to receive with codec 3 once it sends the > offer anyway. > 2. If A wants to restrict the set based on the answer, it can always > generate a new offer with a reduced set of codecs. > 3. SDP has always been interpreted as indicating your own > capabilities, > and is therefore an "advertisement" that sticks until updated. > 4. There are useful cases for adding codecs in the answer, > particularly, > support for rfc2833. Thus, lets say A is an end user which > can send rfc > 2833, but not receive it. So, when it sends an INVITE, it doesn't > include rfc2833 in the INVITE. The server that responds is a media > server, which supports rfc2833. So, it includes it in the > answer. Now, A > can actually send with it during the middle of the session, > and it will > never receive it (since it didn't advertise it). This > provides a useful > function that would otherwise require FID. > > Arguments for NO: > > 1. The purpose of the O/A model is to agree on shared views of certain > session parameters, such as the directionality (send/recv/sendrecv). > Codecs fit into that category as well, since you are already > required to > indicate, in the answer, a set that partially overlaps with the offer. > Furthermore, the goal with codecs is to have the same in both > directions, generally, so that this would speak to them being a shared > state that is negotiated. > > 2. Many people have interpreted the SDP/bis/rfc2543 drafts > this way. If > you go for YES, there may be interop issues. The converse is not true, > of course. > > 3. It is very useful to narrow down the codec sets in the > answer, and we > should not always require an extra exchange of O/A just to do that. > > > > I took a private poll amongst some implementors. The initial results > showed that most assumed the YES case. Some more mails since then > indicate its a bit more split, although I think somewhat in > favor of YES > still. > > I am somewhat on the fence; I think NO is more correct based on > offer/answer, although YES would be the SDP purist view. What I really > want is more opinions on this one.... > > THanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > ------_=_NextPart_001_01C1B8D2.18C967E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] summarizing discussion on codec placement in = answer

Jonathan,

   We at Nortel (that includes at least = four of us including a codec expert) support the second option, i.e., = "NO". The primary reason is the #3 reason that you've - we = would like to have the possibility of narrowing down to one codec = without the overhead of an extra roundtrip (O/A exchange). Also, its = not clear to some of us how would you negotiate the attributes that're = associated with the media session (e.g., security parameters). Example, = suppose Offerer sends 3 codecs - 2,3,4 and the answerer responds with = 3,4 and adds an a=3Dkeymgmt-data: attribute for this media, should the = offerer be ready to accept 2 with the security keys applied?

Thanks,
Sanjoy


> -----Original Message-----
> From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
> Sent: Friday, February 15, 2002 3:32 PM
> To: mmusic@ietf.org
> Subject: [MMUSIC] summarizing discussion on = codec placement in answer
>
>
> Folks,
>
> I wanted to take a moment to summarize where we = were in regards to our
> long thread on interpretation of the codecs in = the answer. The purpose
> of the summarization is to put all the points = on the table, and
> hopefully invite some further comment from = folks outside the
> few thread
> participants in the few days which = remain.
>
> ISSUE:
>
> A sends an offer to B. That offer, for example, = is for a
> single sendrecv
> media stream, which lists codecs 1,2 and 3. The = answerer, B, responds,
> and lists codecs 1 and 2. Now, the question is = this: can B
> still send to
> A using codec 3? Related to that, can B add = codecs in the
> answer, which
> A can then send with?
>
> Arguments for YES:
>
> 1. A needs to be prepared to receive with codec = 3 once it sends the
> offer anyway.
> 2. If A wants to restrict the set based on the = answer, it can always
> generate a new offer with a reduced set of = codecs.
> 3. SDP has always been interpreted as = indicating your own
> capabilities,
> and is therefore an "advertisement" = that sticks until updated.
> 4. There are useful cases for adding codecs in = the answer,
> particularly,
> support for rfc2833. Thus, lets say A is an end = user which
> can send rfc
> 2833, but not receive it. So, when it sends an = INVITE, it doesn't
> include rfc2833 in the INVITE. The server that = responds is a media
> server, which supports rfc2833. So, it includes = it in the
> answer. Now, A
> can actually send with it during the middle of = the session,
> and it will
> never receive it (since it didn't advertise = it). This
> provides a useful
> function that would otherwise require = FID.
>
> Arguments for NO:
>
> 1. The purpose of the O/A model is to agree on = shared views of certain
> session parameters, such as the directionality = (send/recv/sendrecv).
> Codecs fit into that category as well, since = you are already
> required to
> indicate, in the answer, a set that partially = overlaps with the offer.
> Furthermore, the goal with codecs is to have = the same in both
> directions, generally, so that this would speak = to them being a shared
> state that is negotiated.
>
> 2. Many people have interpreted the = SDP/bis/rfc2543 drafts
> this way. If
> you go for YES, there may be interop issues. = The converse is not true,
> of course.
>
> 3. It is very useful to narrow down the codec = sets in the
> answer, and we
> should not always require an extra exchange of = O/A just to do that.
>
>
>
> I took a private poll amongst some = implementors. The initial results
> showed that most assumed the YES case. Some = more mails since then
> indicate its a bit more split, although I think = somewhat in
> favor of YES
> still.
>
> I am somewhat on the fence; I think NO is more = correct based on
> offer/answer, although YES would be the SDP = purist view. What I really
> want is more opinions on this one....
>
> THanks,
> Jonathan R.
>
> --
> Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
> Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
> = dynamicsoft          &= nbsp;           &= nbsp;      East Hanover, NJ 07936
> = jdrosen@dynamicsoft.com        &= nbsp;        FAX: (973) = 952-5050
> http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
> http://www.dynamicsoft.com
>
> _______________________________________________<= /FONT>
> mmusic mailing list
> mmusic@ietf.org
> https://www1.ietf.org/mailman/listinfo/mmusic
>

------_=_NextPart_001_01C1B8D2.18C967E0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 19:57: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 TAA25305 for ; Mon, 18 Feb 2002 19:57:40 -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 TAA23336; Mon, 18 Feb 2002 19:49: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 TAA23300 for ; Mon, 18 Feb 2002 19:49:11 -0500 (EST) Received: from mail2.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25145 for ; Mon, 18 Feb 2002 19:49:07 -0500 (EST) DATE: 19 Feb 2002 00:49:09 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 19 Feb 2002 00:49:10 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id TAA23301 Subject: [MMUSIC] RE: summarizing discussion on codec placement in answer 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 Sanjoy Sen wrote: > Also, its not clear to some of us how would you negotiate the > attributes that're associated with the media session (e.g., security > parameters). Example, suppose Offerer sends 3 codecs - 2,3,4 and the > answerer responds with 3,4 and adds an a=keymgmt-data: attribute for > this media, should the offerer be ready to accept 2 with the security > keys applied? I have a related question: How would the same security parameter negotiation work with early media? ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 21:49:05 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 VAA28413 for ; Mon, 18 Feb 2002 21:49:05 -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 VAA28364; Mon, 18 Feb 2002 21:48:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28332 for ; Mon, 18 Feb 2002 21:48:38 -0500 (EST) Received: from smtp.huawei.com ([61.144.161.21]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28409 for ; Mon, 18 Feb 2002 21:48:31 -0500 (EST) Received: from x18916 ([172.17.254.1]) by smtp.huawei.com (Netscape Messaging Server 4.15) with SMTP id GRRECW00.G2E; Tue, 19 Feb 2002 10:46:08 +0800 Message-ID: <000f01c1b8ef$f0b9fda0$81190b0a@huawei.com.cn> From: "Peili Xu" To: "Jonathan Rosenberg" Cc: References: <003c01c1ad1e$91b273a0$db100b0a@huawei.com.cn> <3C5DF33A.783BB466@dynamicsoft.com> Date: Tue, 19 Feb 2002 10:48:41 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id VAA28333 Subject: [MMUSIC] Re: Question About SDO Offer/Answer 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: 8bit But in bis07 line 2036 it reads: "Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the INVITE. Since only the UAC can send PRACK, this means the a UAS based on this specification alone can never generate subsequent offers. " This means that the UAS cannot start a second offer use 200 and get answer in ACK?? There is a conflict here. ----- Original Message ----- From: Jonathan Rosenberg To: Peili Xu Cc: Sent: Monday, February 04, 2002 10:34 AM Subject: Re: Question About SDO Offer/Answer draft > > > Peili Xu wrote: > > > > In section 4 "Protocol Operatioin": > > > > It says that the agent Must Not generate a new offer if it has received > > an offer which it has not yet answered or rejected. > > > > But for early media we use 180/PRACK to offer and answer the early media > > just before > > > > the Invite/200 interaction is completed. > > > > Is this method break the Offer/Answer law? > > No. It works like this: > > > INVITE (offer 1) --> > <-----183 (answer 1)- > > <------200 OK (offer 2)-- > -------ACK (answer 2)----> > > that is, the 200 OK is a new offer, and then SDP is present in the ACK > with an answer. > > This is different from the "common" practice today for early media, > which has the 183 as an anwer, with a 200 OK that repeats the same SDP. > I believe there will largely be backwards compatibility. If the UAS does > the "common" thing when talking to an element compliant to bis/o-a, it > will send SDP in the ACK, but so long as its not different from the > offer in the INVITE, there won't be any issues. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 18 21:52: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 VAA28457 for ; Mon, 18 Feb 2002 21:52:00 -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 VAA28475; Mon, 18 Feb 2002 21:51:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28412 for ; Mon, 18 Feb 2002 21:51:35 -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 VAA28444 for ; Mon, 18 Feb 2002 21:51:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Mon, 18 Feb 2002 18:49:51 -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); Mon, 18 Feb 2002 18:49:50 -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 g1J2n2MZ008473 for ; Mon, 18 Feb 2002 18:49:02 -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 16d0L0-0001Ot-00 for ; Mon, 18 Feb 2002 18:49: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: Mon, 18 Feb 2002 18:49:02 -0800 X-UIDL: 0c4776f36d7229ded234bb50afc30397 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #22 - 14 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-477421 ] When to send response (noreply@sourceforge.net) 2. [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range (noreply@sourceforge.net) 3. [ rtspspec-Bugs-477424 ] How to queue timed plays? (noreply@sourceforge.net) 4. [ rtspspec-Bugs-477425 ] Inconsistency between timeformats (noreply@sourceforge.net) 5. [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl (noreply@sourceforge.net) 6. [ rtspspec-Bugs-477421 ] When to send response (noreply@sourceforge.net) 7. [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl (noreply@sourceforge.net) 8. [ rtspspec-Bugs-477425 ] Inconsistency between timeformats (noreply@sourceforge.net) 9. [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range (noreply@sourceforge.net) 10. [ rtspspec-Bugs-477427 ] Transport model requirements (noreply@sourceforge.net) 11. [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl (noreply@sourceforge.net) 12. [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate (noreply@sourceforge.net) 13. [ rtspspec-Bugs-513758 ] Proxy-Require clarification (noreply@sourceforge.net) 14. [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 17:10:43 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477421 ] When to send response Bugs item #477421, was opened at 2001-11-01 23:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: When to send response Initial Comment: Server can't respond to a bad request if no sequence number is present in the request. Resulting in that the client does not know that the server has received it and has issues. Please clarify when a server is allowed to send response to bad request. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:10 Message: Logged In: YES user_id=437905 RESOLVED: The Server is allowed to send an immediate response with no sequence number. As a general rule the server should NOT set sequence numbers. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:01 Message: Logged In: YES user_id=3796 This one is going to be up to the server. It can send "Connection: close" if the state machine is too messed up (though see #492546 for another discussion). We can't overspecify this, though. Please suggest text to insert in the specification. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 17:12:15 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range Bugs item #477423, was opened at 2001-11-01 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Unclearities regarding pause with range Initial Comment: How shall the pause point be specifed? Is the only correct way to do it "(start time)- "? The use of range with time? It seem to be unecessary as play with range works instead. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:12 Message: Logged In: YES user_id=437905 RESOLVED: Only a single range specifier (format "value-" where "value" is a time) is allowed for pause. time="execution time in UTC" may also be used, but if multiple range specifiers are present, npt/smpte takes precence over time. A new example will be provided. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:03 Message: Logged In: YES user_id=3796 Does need clarification in specification, but probably warrents discussion. Recommendation: end time in range is ignored ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 17:44:00 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477424 ] How to queue timed plays? Bugs item #477424, was opened at 2001-11-01 23:47 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: How to queue timed plays? Initial Comment: When you queue items that has a activation time, does that override the order of the events that are queued? Play(1) has time A, Play(2) has time B, time A are after time B. Assumption on how it work: First Play(2) activated at time B, then at time B Play(1) tries to start, if already playing, it is queued as a normal untimed event. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:44 Message: Logged In: YES user_id=437905 RESOLVED: Propose elimination of queued play to list. Separate email necessary. RESOLVED: postpone 477424 until queue play is resolved. ACTION ITEM (RL): submit proposal to eliminate queued play. ACTION ITEM (MW): continuous sequence number filing. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:04 Message: Logged In: YES user_id=3796 Interpretation is correct. Do you (or anyone in the working group) have a proposal for text to drop into the spec? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477424&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 17:44:40 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477425 ] Inconsistency between timeformats Bugs item #477425, was opened at 2001-11-01 23:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Inconsistency between timeformats Initial Comment: NPT time in range is allowed to be specifed as "-nptime". No other timeformat allows that, why? ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:44 Message: Logged In: YES user_id=437905 RESOLVED: Extend this to other time formats, and probably clarify the semantics of this particular syntax. Should start at pause point or the beginning. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-01-03 01:07 Message: Logged In: YES user_id=302620 I belive we need to to consider how a play with a range "-time" after a pause should be treated. This is related to #493265. If #493265 alternative 2 is the agreed behaviour for that issue, the -time range could be used to restart a paused media with a given end point. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:06 Message: Logged In: YES user_id=3796 We're pretty sure this is a thinko, and we think that this technique should be extended to the other time formats. Anyone in the working group think differerently? ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 07:44 Message: Logged In: YES user_id=3796 It's clear we need to extend this to other time formats, and probably clarify the semantics of this particular syntax. As to "why?", it was probably just an oversight; we focused on npt for most of our work. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 17:45:21 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl Bugs item #477428, was opened at 2001-11-01 23:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 Category: None Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Priorites between aggregated & non cntrl Initial Comment: A single media stream is playing. Then an aggregated control which include this stream is issued a play. How should this be interpreted? I use that it is queue and waits until all single streams under that aggregated control finish their play. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:45 Message: Logged In: YES user_id=437905 RESOLVED: Await resolution of queued play. Aggregate control issue needs larger discussion. ACTION ITEM: Write up aggregate URL proposal. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 18:02:58 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477421 ] When to send response Bugs item #477421, was opened at 2001-11-01 23:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&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: When to send response Initial Comment: Server can't respond to a bad request if no sequence number is present in the request. Resulting in that the client does not know that the server has received it and has issues. Please clarify when a server is allowed to send response to bad request. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:10 Message: Logged In: YES user_id=437905 RESOLVED: The Server is allowed to send an immediate response with no sequence number. As a general rule the server should NOT set sequence numbers. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:01 Message: Logged In: YES user_id=3796 This one is going to be up to the server. It can send "Connection: close" if the state machine is too messed up (though see #492546 for another discussion). We can't overspecify this, though. Please suggest text to insert in the specification. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 12 Feb 2002 18:03:17 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl Bugs item #477428, was opened at 2001-11-01 23:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&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: Priorites between aggregated & non cntrl Initial Comment: A single media stream is playing. Then an aggregated control which include this stream is issued a play. How should this be interpreted? I use that it is queue and waits until all single streams under that aggregated control finish their play. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:45 Message: Logged In: YES user_id=437905 RESOLVED: Await resolution of queued play. Aggregate control issue needs larger discussion. ACTION ITEM: Write up aggregate URL proposal. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 14 Feb 2002 14:40:40 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477425 ] Inconsistency between timeformats Bugs item #477425, was opened at 2001-11-01 23:48 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&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: Inconsistency between timeformats Initial Comment: NPT time in range is allowed to be specifed as "-nptime". No other timeformat allows that, why? ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:44 Message: Logged In: YES user_id=437905 RESOLVED: Extend this to other time formats, and probably clarify the semantics of this particular syntax. Should start at pause point or the beginning. ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2002-01-03 01:07 Message: Logged In: YES user_id=302620 I belive we need to to consider how a play with a range "-time" after a pause should be treated. This is related to #493265. If #493265 alternative 2 is the agreed behaviour for that issue, the -time range could be used to restart a paused media with a given end point. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:06 Message: Logged In: YES user_id=3796 We're pretty sure this is a thinko, and we think that this technique should be extended to the other time formats. Anyone in the working group think differerently? ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 07:44 Message: Logged In: YES user_id=3796 It's clear we need to extend this to other time formats, and probably clarify the semantics of this particular syntax. As to "why?", it was probably just an oversight; we focused on npt for most of our work. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477425&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 14 Feb 2002 14:41:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477423 ] Unclearities regarding pause with range Bugs item #477423, was opened at 2001-11-01 23:45 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&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: Unclearities regarding pause with range Initial Comment: How shall the pause point be specifed? Is the only correct way to do it "(start time)- "? The use of range with time? It seem to be unecessary as play with range works instead. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:12 Message: Logged In: YES user_id=437905 RESOLVED: Only a single range specifier (format "value-" where "value" is a time) is allowed for pause. time="execution time in UTC" may also be used, but if multiple range specifiers are present, npt/smpte takes precence over time. A new example will be provided. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:03 Message: Logged In: YES user_id=3796 Does need clarification in specification, but probably warrents discussion. Recommendation: end time in range is ignored ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477423&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 14 Feb 2002 14:40:59 -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: 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: 11 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 14 Feb 2002 14:42:13 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477428 ] Priorites between aggregated & non cntrl Bugs item #477428, was opened at 2001-11-01 23:51 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 Category: None >Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Priorites between aggregated & non cntrl Initial Comment: A single media stream is playing. Then an aggregated control which include this stream is issued a play. How should this be interpreted? I use that it is queue and waits until all single streams under that aggregated control finish their play. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:45 Message: Logged In: YES user_id=437905 RESOLVED: Await resolution of queued play. Aggregate control issue needs larger discussion. ACTION ITEM: Write up aggregate URL proposal. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477428&group_id=23194 --__--__-- Message: 12 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 18 Feb 2002 00:31:06 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-518997 ] Mixing aggregate and non-aggregate Bugs item #518997, was opened at 2002-02-18 00:30 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=518997&group_id=23194 Category: General Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Mixing aggregate and non-aggregate Initial Comment: This is a tracking issue for the email here: http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00115.html * Point a) RESOLVED * First point b) RESOLVED * Second point b) MUTE and UNMUTE * RESOLVED: separate draft * ACTION ITEM: Call for authors on MUTE proposed. AN is tentatively signed up * Point C) (same as http://rtsp.org/bug477400) * RESOLVED: PING writeup will be done as part of next RTSP draft...continue discussion on mailing list * RESOLVED: deprecate PLAY w/o range as ping method ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=518997&group_id=23194 --__--__-- Message: 13 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 18 Feb 2002 15:33:25 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-513758 ] Proxy-Require clarification Bugs item #513758, was opened at 2002-02-06 06:16 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513758&group_id=23194 Category: General >Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Proxy-Require clarification Initial Comment: Today the proxy-require method says that the server should treat the proxy-require header identically as require. I don't understand how that mechanism work for paramters/functionallity that only the proxies should answer to. To avoid a negative acknowledgment the server must be aware of these parameters to not place them in the Unsupported header. I can't see that any proxy can modify the response as it will not know if the response comes from a proxy or a server. Can someone please clarify this? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=513758&group_id=23194 --__--__-- Message: 14 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 18 Feb 2002 16:36:49 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted Bugs item #448521, was opened at 2001-08-06 13:01 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Anders Klemets (klemets) Assigned to: Rob Lanphier (robla) Summary: URLs in Rtp-Info need to be quoted Initial Comment: The Rtp-Info header contains URLs, but those URLs are not quoted, causing problems when the URLs contain semi-colon, equal signs and comma characters. The best way to quote URLs are by using double- quotes. Using angle-brackets has also been proposed, but using double-quotes is more likely to be compatbile with existing implementations, because other RTSP/HTTP headers use double-quote characters in similar situations. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-18 16:36 Message: Logged In: YES user_id=3796 This has been fixed in the version in CVS ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:20 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 telecon) Proposed solution was accepted. Alternative use of semicolon and comma were considered by classified as "dangerous characters" ans would break existing implementations. ---------------------------------------------------------------------- Comment By: Henning Schulzrinne (hgschulz) Date: 2002-01-09 09:20 Message: Logged In: YES user_id=115926 URL escaping (%xx) doesn't work since you lose the distinction between syntactically significant semicolons (etc.) and just characters that were escaped in the original URL. Only comma and semicolon need to be escaped, since equal signs are not delimiters. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:26 Message: Logged In: YES user_id=3796 I should probably clarify the comments made yesterday. This is a genuine issue, but it needs to be weighed against backward-compatibility needs. Would like input from implementors on what the best solution is. We would propose the following: * We need to define the problem characters. ";" and "=" are two, there may be others * URLs MUST not be quoted when no problem characters are present in the URL. This will help maintain backwards-compatibilty with current implementations * URLs MUST be quoted when problem characters are present ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-12 14:14 Message: Logged In: YES user_id=3796 add quotes only when sending problem characters (";", "=", ",", need to think further) ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-08-07 07:21 Message: Logged In: YES user_id=3796 This is primarily to test if mail to confctrl is working ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=448521&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 Tue Feb 19 05:18: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 FAA13616 for ; Tue, 19 Feb 2002 05:18: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 FAA25257; Tue, 19 Feb 2002 05:17:52 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA25227 for ; Tue, 19 Feb 2002 05:17:51 -0500 (EST) Received: from accord-ntsrv3.accord-domain ([212.199.61.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13610 for ; Tue, 19 Feb 2002 05:17:44 -0500 (EST) Received: by ACCORD-NTSRV3 with Internet Mail Service (5.5.2653.19) id <1197BNY5>; Tue, 19 Feb 2002 12:17:32 +0200 Message-ID: From: "Even, Roni" To: mmusic@ietf.org Subject: RE: [MMUSIC] summarizing discussion on codec placement in answer Date: Tue, 19 Feb 2002 12:17:31 +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, I would vote for the No. My reasons are that I would like to distinguish between symmetric codecs and non symmetric codecs. I would use the sendrecv if I want symmetric codecs and use recvonly and sendonly if I want non symmetric codecs. The reasons for the different modes is that I may be an MCU that needs the video streams to be symmetric or a terminal that cannot decode one video algorithm and encode another. Point 3 in the no is very important. Roni Even Polycom -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, February 15, 2002 11:32 PM To: mmusic@ietf.org Subject: [MMUSIC] summarizing discussion on codec placement in answer Folks, I wanted to take a moment to summarize where we were in regards to our long thread on interpretation of the codecs in the answer. The purpose of the summarization is to put all the points on the table, and hopefully invite some further comment from folks outside the few thread participants in the few days which remain. ISSUE: A sends an offer to B. That offer, for example, is for a single sendrecv media stream, which lists codecs 1,2 and 3. The answerer, B, responds, and lists codecs 1 and 2. Now, the question is this: can B still send to A using codec 3? Related to that, can B add codecs in the answer, which A can then send with? Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Arguments for NO: 1. The purpose of the O/A model is to agree on shared views of certain session parameters, such as the directionality (send/recv/sendrecv). Codecs fit into that category as well, since you are already required to indicate, in the answer, a set that partially overlaps with the offer. Furthermore, the goal with codecs is to have the same in both directions, generally, so that this would speak to them being a shared state that is negotiated. 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If you go for YES, there may be interop issues. The converse is not true, of course. 3. It is very useful to narrow down the codec sets in the answer, and we should not always require an extra exchange of O/A just to do that. I took a private poll amongst some implementors. The initial results showed that most assumed the YES case. Some more mails since then indicate its a bit more split, although I think somewhat in favor of YES still. I am somewhat on the fence; I think NO is more correct based on offer/answer, although YES would be the SDP purist view. What I really want is more opinions on this one.... THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 19 09:31: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 JAA20665 for ; Tue, 19 Feb 2002 09:31: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 JAA08280; Tue, 19 Feb 2002 09:30: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 JAA08225 for ; Tue, 19 Feb 2002 09:30:32 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20632 for ; Tue, 19 Feb 2002 09:30:29 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1JETcS19087; Tue, 19 Feb 2002 08:29:42 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1JETbt26732; Tue, 19 Feb 2002 08:29:37 -0600 (CST) Received: from lmf.ericsson.se (rmt160196.am.ericsson.se [138.85.160.196]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id IAA10036; Tue, 19 Feb 2002 08:29:35 -0600 (CST) Message-ID: <3C7268E8.F14A195F@lmf.ericsson.se> Date: Tue, 19 Feb 2002 17:02:00 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peili Xu CC: Jonathan Rosenberg , mmusic@ietf.org Subject: Re: [MMUSIC] Re: Question About SDO Offer/Answer draft References: <003c01c1ad1e$91b273a0$db100b0a@huawei.com.cn> <3C5DF33A.783BB466@dynamicsoft.com> <000f01c1b8ef$f0b9fda0$81190b0a@huawei.com.cn> 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, Peili Xu wrote: > > But in bis07 line 2036 it reads: > "Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent > offers in any responses to the INVITE. Since only the UAC can send PRACK, this means the a UAS > based on this specification alone can never generate subsequent offers. " > > This means that the UAS cannot start a second offer use 200 and get answer in ACK?? > If at the same time that the UAS is sending a new offer in the 200 OK the UAC is sending an UPDATE, we will have a glare condition. But the UAC has no way of rejecting the offer in the 200 OK (SIP does not have a NACK method). That's why this is disallowed. Regards, Gonzalo _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 19 11:30: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 LAA26346 for ; Tue, 19 Feb 2002 11:30: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 LAA16491; Tue, 19 Feb 2002 11:30: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 LAA16452 for ; Tue, 19 Feb 2002 11:30:08 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26337 for ; Tue, 19 Feb 2002 11:30:06 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1JGTOO19372; Tue, 19 Feb 2002 10:29:24 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H2267Z>; Tue, 19 Feb 2002 10:29:24 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A0311A13D@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Roman Shpount'" , "Sanjoy Sen", jdrosen@dynamicsoft.com, mmusic@ietf.org Cc: "'msec@securemulticast.org'" Subject: RE: [MMUSIC] RE: summarizing discussion on codec placement in ans wer Date: Tue, 19 Feb 2002 10:29:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B962.918E24F0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B962.918E24F0 Content-Type: text/plain; charset="iso-8859-1" Hi, If we assume that we are talking about SRTP (draft-ietf-avt-srtp-02.txt) with the key exchange mechanism/SDP extensions being defined in draft-ietf-msec-mikey-00.txt and draft-ietf-mmusic-kmgmt-ext-01.txt, respectively, then there should be no ambiguity with early media solution(s) provided that the new proposed SDP attribute "a=keymgmt-data:" contains based-64 encoded MIKEY payloads in the UPDATE request method contains all of the parameters (e.g., SSRC,etc.) required to create a cryptographic context(s) (...and then provided that the response code to the UPDATE request method accepts the codec(s) offered to it). The potential problem with the previous e-mail regarding offer/answer issue related to a conflict regarding the sending of "a=keymgmt-data:" in SDP with, for example, 3 cryptographic context(s) (3 SSRCs) but only two codec(s). See below. Thanks. Regards, Pete -----Original Message----- From: Roman Shpount [mailto:roman@atelo.com] Sent: Monday, February 18, 2002 6:49 PM To: Sen, Sanjoy [NGC:B692:EXCH]; jdrosen@dynamicsoft.com; mmusic@ietf.org Subject: [MMUSIC] RE: summarizing discussion on codec placement in answer Sanjoy Sen wrote: > Also, its not clear to some of us how would you negotiate the > attributes that're associated with the media session (e.g., security > parameters). Example, suppose Offerer sends 3 codecs - 2,3,4 and the > answerer responds with 3,4 and adds an a=keymgmt-data: attribute for > this media, should the offerer be ready to accept 2 with the security > keys applied? I have a related question: How would the same security parameter negotiation work with early media? ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C1B962.918E24F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] RE: summarizing discussion on codec placement in = answer

Hi,

If we assume that we are talking about SRTP = (draft-ietf-avt-srtp-02.txt) with the key exchange mechanism/SDP = extensions being defined in draft-ietf-msec-mikey-00.txt and = draft-ietf-mmusic-kmgmt-ext-01.txt, respectively, then there should be = no ambiguity with early media solution(s) provided that the new = proposed SDP attribute "a=3Dkeymgmt-data:" contains based-64 = encoded MIKEY payloads in the UPDATE request method contains all of the = parameters (e.g., SSRC,etc.) required to create a cryptographic = context(s) (...and then provided that the response code to the UPDATE = request method accepts the codec(s) offered to it).

The potential problem with the previous e-mail = regarding offer/answer issue related to a conflict regarding the = sending of "a=3Dkeymgmt-data:" in SDP with, for example, 3 = cryptographic context(s) (3 SSRCs) but only two codec(s). See below. = Thanks.

Regards,

Pete

-----Original Message-----
From: Roman Shpount [mailto:roman@atelo.com]
Sent: Monday, February 18, 2002 6:49 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; = jdrosen@dynamicsoft.com;
mmusic@ietf.org
Subject: [MMUSIC] RE: summarizing discussion on = codec placement in
answer


Sanjoy Sen wrote:

> Also, its not clear to some of us how would you = negotiate the
> attributes that're associated with the media = session (e.g., security
> parameters). Example, suppose Offerer sends 3 = codecs - 2,3,4 and the
> answerer responds with 3,4 and adds an = a=3Dkeymgmt-data: attribute for
> this media, should the offerer be ready to = accept 2 with the security
> keys applied?

I have a related question: How would the same = security parameter negotiation work with early media?
___________________________________
Roman Shpount, VP of Technology
aTelo, Inc.
2107 Wilson Blvd., Suite 301
Arlington, VA 22201
PCN: 703-621-4040 for voice / fax
www.atelo.com






_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------_=_NextPart_001_01C1B962.918E24F0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 19 15:33: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 PAA04576 for ; Tue, 19 Feb 2002 15:33:52 -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 PAA01540; Tue, 19 Feb 2002 15:33:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA01505 for ; Tue, 19 Feb 2002 15:33:25 -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 PAA04568 for ; Tue, 19 Feb 2002 15:33:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 19 Feb 2002 12:31:41 -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); Tue, 19 Feb 2002 12:31:41 -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 g1JKXGMZ010464 for ; Tue, 19 Feb 2002 12:33:16 -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 16dGwp-00085U-00 for ; Tue, 19 Feb 2002 12:33:11 -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: Tue, 19 Feb 2002 12:33:11 -0800 X-Spam-Status: No, hits=1.2 required=5.5 tests=NO_REAL_NAME version=2.1 X-UIDL: 77b23f2c5866ef0655c16e30e793a6db To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #23 - 1 msg 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-461083 ] Body w/o Content-Length clarification (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 18 Feb 2002 16:52:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification Bugs item #461083, was opened at 2001-09-12 18:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&group_id=23194 Category: General >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Jason Lango (jasonlango) Assigned to: Rob Lanphier (robla) Summary: Body w/o Content-Length clarification Initial Comment: RFC 2326 says: 4.4 Message Length When a message body is included with a message, the length of that body is determined by one of the following (in order of precedence): 1. Any response message which MUST NOT include a message body (such as the 1xx, 204, and 304 responses) is always terminated by the first empty line after the header fields, regardless of the entity-header fields present in the message. (Note: An empty line consists of only CRLF.) 2. If a Content-Length header field (section 12.14) is present, its value in bytes represents the length of the message-body. If this header field is not present, a value of zero is assumed. 3. By the server closing the connection. (Closing the connection cannot be used to indicate the end of a request body, since that would leave no possibility for the server to send back a response.) .. so it is saying that closing the connection is Ok to indicate the length. .. but then in section 12.14, it also says that the Content-Length header MUST be sent. The two sections should probably be made consistent. Currently a popular RTSP server implementation (QTSS) sends "Connection: Close" followed by a message body for certain RTSP error status responses. It might be worth requiring 'Connection: Close' in item 3 of section 4.4 to reduce the ambiguity of whether or not a compatible implementation may expect a response to contain a message body. Alternatively it might be worth -not- saying that message length may be determined by the server closing the connection. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-18 16:52 Message: Logged In: YES user_id=3796 Eliminated item #3 from the list. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:28 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 teleconference) Eliminate implicit body-length via connection: close. COntactt David SInger on this issues and encourage f future participation. Verify resolution is consistent with SIP specificaiton. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:32 Message: Logged In: YES user_id=3796 This is a potentially gnarly issue. We agree that this is a problem that needs fixing. We propose that we eliminate the option of implied Content-Length if possible (need to check with implementors on this....Darwin server in particular). If we can't do that, require Connection: close, and change header definition. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=461083&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 Wed Feb 20 01:47: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 BAA15948 for ; Wed, 20 Feb 2002 01:47: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 BAA04908; Wed, 20 Feb 2002 01:44: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 BAA04874 for ; Wed, 20 Feb 2002 01:44:06 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15914 for ; Wed, 20 Feb 2002 01:44:04 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1K6iF6Y010374; Wed, 20 Feb 2002 01:44:15 -0500 (EST) Message-ID: <3C73458C.B5E46033@dynamicsoft.com> Date: Wed, 20 Feb 2002 01:43:24 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: sanjoy@nortelnetworks.com, mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: summarizing discussion on codec placement in answer 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 Roman Shpount wrote: > > Sanjoy Sen wrote: > > > Also, its not clear to some of us how would you negotiate the > > attributes that're associated with the media session (e.g., security > > parameters). Example, suppose Offerer sends 3 codecs - 2,3,4 and the > > answerer responds with 3,4 and adds an a=keymgmt-data: attribute for > > this media, should the offerer be ready to accept 2 with the security > > keys applied? That just doesn't work. My understanding of the a-keymngmt-data attribute is that it is a tunnel for mikey. MIKEY, as I understand it, requires a two pass exchange. Thus, you would have to have this attribute in the offer and the answer for this to work. The a=keymngmt-data attribute is hardly a normal session attribute, for this reason. As far as other attributes are concerned, some may be negoiated (like the directional ones), and others are merely declarative (like ptime) such that there is no relationship between the values in the offer and the answer. I think the current o/a doc points this out. There is no general way to know which case it is for a particular attribute. > > I have a related question: How would the same security parameter > negotiation work with early media? No different! Thats the entire idea behind the unify proposal. With unify, early media is just an O/A exchange that finishes before the sip invite transaction does. Since mikey will work by embedding in any O/A exchange, as far as I can tell, the fact that the exchange is before the sip transaction is completed is totally irrelevant. Please do read the unify draft: http://search.ietf.org/internet-drafts/draft-rosenberg-sip-unify-00.txt -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 20 01:51: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 BAA16018 for ; Wed, 20 Feb 2002 01:51:27 -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 BAA05297; Wed, 20 Feb 2002 01:50: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 BAA05256 for ; Wed, 20 Feb 2002 01:50:49 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16008 for ; Wed, 20 Feb 2002 01:50:47 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1K6p26Y010383; Wed, 20 Feb 2002 01:51:04 -0500 (EST) Message-ID: <3C734723.DCB9AE66@dynamicsoft.com> Date: Wed, 20 Feb 2002 01:50:11 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Peili Xu CC: mmusic@ietf.org References: <000f01c1b8ef$f0b9fda0$81190b0a@huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Question About SDO Offer/Answer 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 Peili Xu wrote: > > But in bis07 line 2036 it reads: > "Once the UAS has sent or received an answer to the initial offer, it > MUST NOT generate subsequent > offers in any responses to the INVITE. Since only the UAC can send > PRACK, this means the a UAS > based on this specification alone can never generate subsequent offers. > " > > This means that the UAS cannot start a second offer use 200 and get > answer in ACK?? Right, for the reasons Gonzalo has outlined. > > There is a conflict here. Indeed. I suspect my response, which you quote below, was sent before I had fully worked it all out, or that I was just plain confused. Either way, my apologies. -Jonathan R. > > ----- Original Message ----- > From: Jonathan Rosenberg > To: Peili Xu > Cc: > Sent: Monday, February 04, 2002 10:34 AM > Subject: Re: Question About SDO Offer/Answer draft > > > > > > > Peili Xu wrote: > > > > > > In section 4 "Protocol Operatioin": > > > > > > It says that the agent Must Not generate a new offer if it has > received > > > an offer which it has not yet answered or rejected. > > > > > > But for early media we use 180/PRACK to offer and answer the early > media > > > just before > > > > > > the Invite/200 interaction is completed. > > > > > > Is this method break the Offer/Answer law? > > > > No. It works like this: > > > > > > INVITE (offer 1) --> > > <-----183 (answer 1)- > > > > <------200 OK (offer 2)-- > > -------ACK (answer 2)----> > > > > that is, the 200 OK is a new offer, and then SDP is present in the ACK > > with an answer. > > > > This is different from the "common" practice today for early media, > > which has the 183 as an anwer, with a 200 OK that repeats the same > SDP. > > I believe there will largely be backwards compatibility. If the UAS > does > > the "common" thing when talking to an element compliant to bis/o-a, it > > will send SDP in the ACK, but so long as its not different from the > > offer in the INVITE, there won't be any issues. > > > > -Jonathan R. > > > > > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 20 10:50: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 KAA04448 for ; Wed, 20 Feb 2002 10:50: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 KAA00754; Wed, 20 Feb 2002 10:48:26 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA00723 for ; Wed, 20 Feb 2002 10:48:25 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04367 for ; Wed, 20 Feb 2002 10:48:21 -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 g1KFOBhM026008 for ; Wed, 20 Feb 2002 16:24:11 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id QAA09628; Wed, 20 Feb 2002 16:24:11 +0100 Message-ID: <3C73BF9A.5AFE15A7@era.ericsson.se> Date: Wed, 20 Feb 2002 16:24:11 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP state machine 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 RTSP interested people, Here comes an updated RTSP state machine which tries to clarify the different transactions possible and their differences in functionality. It is based on the current proposal for handling aggregated and non-aggregated control. PAUSE and PLAY can't be used on individual media. If that is allowed there will be a number of extra versions of transitions with requirements on the different media state. It reflects my understanding of the currently proposed functionality and I hope that intressted people take the time to at least read through it. Please comment if you have questions or found errors or omitted things. The goal is that this state machine will help give a common view and understanding. This state machine does not contain RECORD which needs to be added. State transitions not present are not allowed. Some RTSP methods like options, and SET_PARAMETER does not effect these states. States Explanation ----------------------------------------------------------------------- Init Initial state no session exist Ready-na Non aggregated session in Ready state Playing-na Non aggregated session in Playing state Paused-na Non aggregated session in Paused state Ready-a Aggregated session in Ready state Playing-a Aggregated session in Playing Paused-a Aggregated session in Pause The reason for separating aggregated and non aggregated states are the following: - Play and Pause may only be done on aggregate URL and not media URLs in aggregated control. In non-aggregated the two are the same. State variables --------------- Nr-media The number of media which are currently ready. State: Init Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP Ready-na Nr-media = 1 State: Ready-na Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media = 2 SETUP Present URL Ready-na Change transport param. TEARDOWN Init Ok PLAY No range Playing-na from beginning of media PLAY Range Playing-na according to range Timeout Init State: Playing-na Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY Playing-na Queue play PAUSE No range Paused-na Set pause-point PAUSE Range > now Playing-na Set pause-point Pause point reached Paused-na End of media Ready-na Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL, Allowed? Playing-na Change transport param. TEARDOWN Allowed? Init State: Paused-na Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY No range Playing-na Play from pause point PLAY Range Playing-na according to range Timeout Init SETUP New URL Paused-a Nr-media +=1 SETUP Present URL Ready-na Change transport param. TEARDOWN Init State: Ready-a Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media +=1 SETUP Present URL Ready-a Change transport param. TEARDOWN Nr-media >2 Ready-a Nr-media -=1 TEARDOWN Nr-media == 2 Ready-na Nr-media = 1 Timeout Init PLAY No range,AggURL Playing-a from beginning of media PLAY Range, Agg URL Playing-a according to range State: Playing-a Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY Playing-a Queue play PAUSE No range Paused-a Set pause-point PAUSE Range > now Playing-a Set pause-point Pause point reached Paused-a End of media >=1 Media plays Playing-a End of media All media ended Ready-a Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL,Allowed? Ready-na Change transport param. TEARDOWN Allowed? Nr-m>2 Playing-a Nr-media -=1 TEARDOWN Allowed? Nr-m=2 Playing-na Nr-media = 1 State: Paused-a Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY No range Playing-a Play from pause point PLAY Range Playing-a according to range Timeout Init SETUP New URL Paused-a Nr-media +=1 SETUP Present URL Ready-na Change transport param. TEARDOWN Nr-media >2 Paused-a Nr-media -=1 TEARDOWN Nr-media == 2 Paused-na Nr-media = 1 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 20 13:57: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 NAA15975 for ; Wed, 20 Feb 2002 13:57:58 -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 NAA13991; Wed, 20 Feb 2002 13:57:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13955 for ; Wed, 20 Feb 2002 13:57:16 -0500 (EST) Received: from penguin-ext.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 NAA15953 for ; Wed, 20 Feb 2002 13:57:13 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1KIuiB27910; Wed, 20 Feb 2002 19:56:44 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id TAA15535; Wed, 20 Feb 2002 19:56:44 +0100 Message-ID: <3C73F16C.53818D81@era.ericsson.se> Date: Wed, 20 Feb 2002 19:56:44 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "rtspspec-logistics@lists.sourceforge.net" , IETF MMUSIC WG Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RTSP state machine 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 again! I made some errors in the table and I guess there may be some more still in there. Anyway, here is a new version. RTSP state machine ver. 0.2 This state machine does not contain RECORD which needs to be added. 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. Does not include queued play either. 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. States Explanation ----------------------------------------------------------------------- Init Initial state no session exist Ready-na Non aggregated session in Ready state Playing-na Non aggregated session in Playing state Paused-na Non aggregated session in Paused state Ready-a Aggregated session in Ready state Playing-a Aggregated session in Playing Paused-a Aggregated session in Pause The reason for separating aggregated and non aggregated states are the following: - Play and Pause may only be done on aggregate URL and not media URLs in aggregated control. In non-aggregated the two are the same. - State variables --------------- Nr-media State: Init Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP Ready-na Nr-media = 1 State: Ready-na Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media = 2 SETUP Present URL Ready-na Change transport param. Teardown *|media URL Init Ok PLAY No range Playing-na from beginning of media PLAY Range Playing-na according to range Timeout Init State: Playing-na Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE No range Paused-na Set pause point PAUSE Range > now Playing-na Set pause point Pause-point reached Paused-na End of media Ready-na Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL, Allowed? Playing-na Change transport param. TEARDOWN Allowed? Init State: Paused-na Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY No range Playing-na Play from pause point PLAY Range Playing-na according to range Timeout Init SETUP New URL Paused-a Nr-media +=1 SETUP Present URL Ready-na Change transport param. TEARDOWN *|media URL Init State: Ready-a Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media +=1 SETUP Present mediaURL Ready-a Change transport param. TEARDOWN * | Pres URL Init No session hdr. TEARDOWN Nr-media >2 Ready-a Nr-media -=1, sess hdr TEARDOWN Nr-media == 2 Ready-na Nr-media = 1, sess hdr Timeout Init PLAY No range,AggURL Playing-a from beginning of media PLAY Range, Agg URL Playing-a according to range State: Playing-a Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE No range Paused-a Set pause point PAUSE Range > now Playing-a Set point to pause at Pause-point reached Paused-a Set pause point End of media >=1 Media plays Playing-a End of media All media ended Ready-a Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL,Allowed? Playing-a Change transport param TEARDOWN *|pres URL Init No session hdr allowed? TEARDOWN Allowed? Nr-m>2 Playing-a Nr-media -=1, sess hdr TEARDOWN Allowed? Nr-m=2 Playing-na Nr-media = 1, sess hdr State: Paused-a Action Prerequisite New State Response ----------------------------------------------------------------------- PLAY No range Playing-a Play from pause point PLAY Range Playing-a according to range Timeout Init SETUP New URL Paused-a Nr-media +=1 SETUP Present URL Paused-a Change transport param. TEARDOWN *|pres URL Init TEARDOWN Nr-media >2 Paused-a Nr-media -=1 TEARDOWN Nr-media == 2 Paused-na Nr-media = 1 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 Wed Feb 20 20: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 UAA25566 for ; Wed, 20 Feb 2002 20:29: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 UAA04277; Wed, 20 Feb 2002 20:26:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA04237 for ; Wed, 20 Feb 2002 20:26:33 -0500 (EST) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25534; Wed, 20 Feb 2002 20:26:30 -0500 (EST) Received: from cannon.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1L1PmO02510; Wed, 20 Feb 2002 20:25:48 -0500 (EST) Received: from cisco.com (dhcp-161-44-241-140.cisco.com [161.44.241.140]) by cannon.cisco.com (Mirapoint) with ESMTP id AAF54788; Wed, 20 Feb 2002 20:28:40 -0500 (EST) Message-ID: <3C744B13.95D7A388@cisco.com> Date: Wed, 20 Feb 2002 20:19:15 -0500 From: Paul Kyzivat X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: mmusic@ietf.org, sip@ietf.org, sip-implementors@cs.columbia.edu References: <3C5986B7.8DB8FF31@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Sip-implementors] updated offer/answer 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 Sorry to be slow commenting - I am backed up on my reading. I have one possible nit. You have incorporated a:inactive as the replacement for c=0.0.0.0 for hold, and indicated that use of c=0.0.0.0 is deprecated though it still must be supported by recipients. I think it is a bit strong to say that it is deprecated. There are still cases where it is *needed*. In particular, a B2BUA may need to offer on hold to solicit an answer, with the intent to make a new offer later after another offer/answer exchange with another party. In this case, it may not desire or be capable of receiving RTCP, or of providing an address/port to do so. The C=0.0.0.0 provides an effective solution in this case. So, rather than being deprecated for all use, I think the use of c=0.0.0.0 ought to be be more narrowly restricted. Paul Jonathan Rosenberg wrote: > > Folks, > > I have just submitted an update to the offer/answer model draft. Until > it appears in the archives, you can pick it up at: > > http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-00.txt > > This draft includes all of the changes agreed to since IETF 52 and on > the list since then. There are no open issues that I am aware of. > > Perhaps the most substantial change is the allowance of different > payload type numbers in each direction, as per list discussion on > mmusic. Other changes are noted in the changes section. > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 03:34: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 DAA10907 for ; Thu, 21 Feb 2002 03:34:40 -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 DAA03509; Thu, 21 Feb 2002 03:34: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 DAA03478 for ; Thu, 21 Feb 2002 03:34:11 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10865 for ; Thu, 21 Feb 2002 03:34:09 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L8YW6Y012366; Thu, 21 Feb 2002 03:34:32 -0500 (EST) Message-ID: <3C74B0E6.A9241D@dynamicsoft.com> Date: Thu, 21 Feb 2002 03:33:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: mmusic@ietf.org References: <3C744B13.95D7A388@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Sip-implementors] updated offer/answer 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 Well, technically, working group last call has ended, and I am about to submit this draft. But, since this was easy, I incorporated your comment. The text now reads: RFC 2543 specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. An agent {\MUST} be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer. Thanks, Jonathan R. Paul Kyzivat wrote: > > Sorry to be slow commenting - I am backed up on my reading. > > I have one possible nit. You have incorporated a:inactive as the > replacement for c=0.0.0.0 for hold, and indicated that use of c=0.0.0.0 > is deprecated though it still must be supported by recipients. > > I think it is a bit strong to say that it is deprecated. There are still > cases where it is *needed*. In particular, a B2BUA may need to offer on > hold to solicit an answer, with the intent to make a new offer later > after another offer/answer exchange with another party. In this case, it > may not desire or be capable of receiving RTCP, or of providing an > address/port to do so. The C=0.0.0.0 provides an effective solution in > this case. > > So, rather than being deprecated for all use, I think the use of > c=0.0.0.0 ought to be be more narrowly restricted. > > Paul > > Jonathan Rosenberg wrote: > > > > Folks, > > > > I have just submitted an update to the offer/answer model draft. Until > > it appears in the archives, you can pick it up at: > > > > > http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-00.txt > > > > This draft includes all of the changes agreed to since IETF 52 and on > > the list since then. There are no open issues that I am aware of. > > > > Perhaps the most substantial change is the allowance of different > > payload type numbers in each direction, as per list discussion on > > mmusic. Other changes are noted in the changes section. > > > > Thanks, > > Jonathan R. > > -- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PH: (973) 952-5000 > > http://www.dynamicsoft.com > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@cs.columbia.edu > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 03:59: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 DAA11234 for ; Thu, 21 Feb 2002 03:59:37 -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 DAA04804; Thu, 21 Feb 2002 03:59:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA04771 for ; Thu, 21 Feb 2002 03:59:04 -0500 (EST) 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 DAA11230 for ; Thu, 21 Feb 2002 03:59:01 -0500 (EST) 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 g1L8wx401551; Thu, 21 Feb 2002 09:58:59 +0100 (MET) Message-ID: <3C74B6D4.B0A4E5F7@tzi.uni-bremen.de> Date: Thu, 21 Feb 2002 09:59:00 +0100 From: Joerg Ott X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org, jdrosen@dynamicsoft.com, csp@isi.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Another Offer/answer summary 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 Folks, we need to reach closure on this issue fairly shortly. Having gone through the mailing list discussion, we believe that we can narrow down Jonathan's summary a bit further and come up with a concrete proposal to beat up: Restating the issue: > A sends an offer to B. That offer, for example, is for a single sendrecv > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > and lists codecs 1 and 2. Now, the question is this: can B still send to > A using codec 3? Related to that, can B add codecs in the answer, which > A can then send with? Let us keep in mind that we are not designing offer/answer for telephony but that telephony is rather one (maybe not unimportant) special case of multimedia communications. Let us also keep in mind that we should optimize for the more common cases but at the same time not lose generality. And let us not forget that SIP is just *one* customer of offer/answer. Let us assume for a moment that we follow the "NO" proposal (and assume further that this approach does not break interoperability/backward compatility): 1. This idea allows us to narrow down codecs in an efficient fashion. This helps people who do not want to require their implementations to listen for multiple codecs simultaneously (e.g. because of limited DSP resources or difficulties in implementing MCUs). The counter-argument is that such device need to be able to support multiple codecs in the beginning anyway because of the race condition between the answer and the first RTP packet. However, this can be circumvent this by simply waiting for the answer before accepting media at the risk of clipping. But people may be able to architected their network in a way that it does not delay the answer unncessarily and thus avoid clipping in the first place). Alternatively, they may guess which type of codec to expect or only load the decoder upon arrival of the first packet (assuming this is not going to change) at the expense of some additional delay, etc. Looks like there are sufficient alternatives that clipping can be considered a non-issue. (Please note that if you are doing security handshakes and QoS preconditions or similar stuff, you are not going to worry about this type of clipping anyway -- but rather about post- dial delay.) 2. Expanding the codec set can be done by means of an extra offer in the opposite direction. This is an extra exchange but we would assume this to be the less common case (and thus not optimize for it). The only application scenario for which this is really needed people have mentioned so far is DTMF -- more specifically, combining a sendrecv and an sendonly/recvonly media stream. Please share ideas for others with us. We do acknowledge that this scenario is important and need support. But we also judge that this is not the common case and need not be optimized for at all cost if a cleaner solution exists. This cleaner solution can be based upon FID. In the simplest case, A uses FID from the very beginning: A ---- INVITE ----> B a=group:FID 1 2 m=audio pt=0 a=mid:1 m=audio pt=97 a=rtpmap:97 telephone-events a=mid:2 a=sendonly and B can then decide whether or not to reject telephone events. However, A may or may not understand FID and may or may not indicate its send capabilities as described above. Then we get the following simple exchange for A calling B: A ---- INVITE ----> B m=audio pt=0 A <--- 200 OK ----- B m=audio pt=0 A ---- ACK ----> B Now B can indicate its receive caps using FID doing a re-INVITE. A <--- INVITE ----- B a=group:FID 1 2 m=audio pt=0 a=mid:1 m=audio pt=97 a=rtpmap:97 telephone-events a=mid:2 a=recvonly ... Again, we can properly express the intended semantics. If A does not support FID it ignores the attributes thus yielding the following in A's perception: A <--- INVITE ----- B m=audio pt=0 m=audio pt=97 a=rtpmap:97 telephone-events ... This is the alternative that can be pursued without FID (and, at the same time serves as fallback). According to the rules defined in offer/answer for local processing of multiple streams of the same type with one local source or sink, this should just work. The sender copies the input to all streams if the data can be mapped (i.e. only events go across the second media session), the receiver mixes the the incoming data streams locally as appropriate. In a gateway this may sometimes mean to locally generate DTMF tones and mix them with audio signals, sometimes mean to locally sink the DTMF and process it. Jonathan, is this interpretation correct? Is there need for clarifying text on this issue regarding offer/answer? The major issue to discuss here is whether or not there is an extra RTT required for this signaling (or whether other SIP methods can be used to achieve this more quickly) -- and whether the additional delay (whatever this may be) is an issue for DTMF. Thoughts? Is this a viable approach ahead? Note that we are not religious about this proposal -- but it seems to be a reasonable way ahead taking into account some general design principles. There may be other ways and if better ones are found, such proposals are welcome. But they need to be found NOW. A small disclaimer in the end: probably we should be taking the more purist SDP view (as Jonathan calles the "YES" approach) -- but since SDP is used in a way it was not supposed to be anyway the NO method may not cause too much *extra* headache. Colin and Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 04:02: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 EAA11325 for ; Thu, 21 Feb 2002 04:02:58 -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 EAA05400; Thu, 21 Feb 2002 04:02:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA05366 for ; Thu, 21 Feb 2002 04:02:29 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11315 for ; Thu, 21 Feb 2002 04:02:27 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1L92o6Y012383 for ; Thu, 21 Feb 2002 04:02:50 -0500 (EST) Message-ID: <3C74B789.C83A5315@dynamicsoft.com> Date: Thu, 21 Feb 2002 04:02:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org Subject: Re: [MMUSIC] summarizing discussion on codec placement in answer References: <3C6D7E3D.4A18EC33@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Well, the time has arrived for me to make a judgement call, and put some text into offer/answer. I think a sensible approach is a compromise. I phrased the question thusly: > ISSUE: > > A sends an offer to B. That offer, for example, is for a single sendrecv > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > and lists codecs 1 and 2. Now, the question is this: can B still send to > A using codec 3? Related to that, can B add codecs in the answer, which > A can then send with? There are two questions in there. I had assumed that both needed the same answer, but they don't. Most of the advocates of NO want it because of the first question (narrowing down the set). Most of the advocates of YES wanted it because of the second question. So, let us do both. NO to first, YES to second. This is actually consistent; the consistency is that the answer contains the final set, whether it be a larger or smaller one. Specifically, for a sendrecv stream, the answerer MUST NOT send using any media formats not present in both the offer and answer. It MUST be prepared to receive with any codecs in the answer. The offerer MUST NOT send using any media formats not present in the answer, and it MUST be prepared to receive using any media formats in the offer which were also in the answer. Similarly, for an sendonly offer, the answerer can add media formats to the answer (or put fewer). For a recvonly offer, the answerer cannot add any formats (it makes no sense). This is not set in stone; there is the opportunity to modify this during IESG last call, but it seems a reasonable compromise position. Thanks, Jonathan R. Jonathan Rosenberg wrote: > > Folks, > > I wanted to take a moment to summarize where we were in regards to our > long thread on interpretation of the codecs in the answer. The purpose > of the summarization is to put all the points on the table, and > hopefully invite some further comment from folks outside the few thread > participants in the few days which remain. > > ISSUE: > > A sends an offer to B. That offer, for example, is for a single sendrecv > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > and lists codecs 1 and 2. Now, the question is this: can B still send to > A using codec 3? Related to that, can B add codecs in the answer, which > A can then send with? > > Arguments for YES: > > 1. A needs to be prepared to receive with codec 3 once it sends the > offer anyway. > 2. If A wants to restrict the set based on the answer, it can always > generate a new offer with a reduced set of codecs. > 3. SDP has always been interpreted as indicating your own capabilities, > and is therefore an "advertisement" that sticks until updated. > 4. There are useful cases for adding codecs in the answer, particularly, > support for rfc2833. Thus, lets say A is an end user which can send rfc > 2833, but not receive it. So, when it sends an INVITE, it doesn't > include rfc2833 in the INVITE. The server that responds is a media > server, which supports rfc2833. So, it includes it in the answer. Now, A > can actually send with it during the middle of the session, and it will > never receive it (since it didn't advertise it). This provides a useful > function that would otherwise require FID. > > Arguments for NO: > > 1. The purpose of the O/A model is to agree on shared views of certain > session parameters, such as the directionality (send/recv/sendrecv). > Codecs fit into that category as well, since you are already required to > indicate, in the answer, a set that partially overlaps with the offer. > Furthermore, the goal with codecs is to have the same in both > directions, generally, so that this would speak to them being a shared > state that is negotiated. > > 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If > you go for YES, there may be interop issues. The converse is not true, > of course. > > 3. It is very useful to narrow down the codec sets in the answer, and we > should not always require an extra exchange of O/A just to do that. > > I took a private poll amongst some implementors. The initial results > showed that most assumed the YES case. Some more mails since then > indicate its a bit more split, although I think somewhat in favor of YES > still. > > I am somewhat on the fence; I think NO is more correct based on > offer/answer, although YES would be the SDP purist view. What I really > want is more opinions on this one.... > > THanks, > Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PH: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 07:08:21 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 HAA14380 for ; Thu, 21 Feb 2002 07:08:21 -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 HAA15536; Thu, 21 Feb 2002 07:01: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 HAA15463 for ; Thu, 21 Feb 2002 07:01:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14143; Thu, 21 Feb 2002 07:01:44 -0500 (EST) Message-Id: <200202211201.HAA14143@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 21 Feb 2002 07:01:44 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp4nat-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 --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 : RTCP attribute in SDP Author(s) : C. Huitema Filename : draft-ietf-mmusic-sdp4nat-01.txt Pages : 7 Date : 20-Feb-02 The session description protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these port have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp4nat-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp4nat-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020220135135.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp4nat-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp4nat-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020220135135.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 Feb 21 07:08:21 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 HAA14381 for ; Thu, 21 Feb 2002 07:08:21 -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 HAA15456; Thu, 21 Feb 2002 07:01:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA15421 for ; Thu, 21 Feb 2002 07:01:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14127; Thu, 21 Feb 2002 07:01:39 -0500 (EST) Message-Id: <200202211201.HAA14127@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 21 Feb 2002 07:01:38 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-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 : Key Management Extensions for SDP and RTSP Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-02.txt Pages : 11 Date : 20-Feb-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-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-kmgmt-ext-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-kmgmt-ext-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: <20020220135122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020220135122.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 Feb 21 07:08:31 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 HAA14404 for ; Thu, 21 Feb 2002 07:08:31 -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 HAA15401; Thu, 21 Feb 2002 07:01: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 HAA15369 for ; Thu, 21 Feb 2002 07:01:00 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14002; Thu, 21 Feb 2002 07:00:58 -0500 (EST) Message-Id: <200202211200.HAA14002@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 21 Feb 2002 07:00:57 -0500 Subject: [MMUSIC] I-D ACTION:draft-burger-mrcp-reqts-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 : Requirements for Distributed Control of ASR and TTS Resources Author(s) : E. Burger, D. Oran Filename : draft-burger-mrcp-reqts-00.txt Pages : 8 Date : 20-Feb-02 This document outlines the needs and requirements for a protocol to control distributed speech processing of audio streams. By speech processing, this document specifically means automatic speech recognition and text-to-speech. Other IETF protocols, such as SIP and RTSP, address rendezvous and control for generalized media streams. However, speech processing presents additional requirements that none of the extant IETF protocols address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-burger-mrcp-reqts-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-burger-mrcp-reqts-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-burger-mrcp-reqts-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: <20020220134952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-burger-mrcp-reqts-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-burger-mrcp-reqts-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020220134952.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 Feb 21 08:50: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 IAA17019 for ; Thu, 21 Feb 2002 08:50:49 -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 IAA21577; Thu, 21 Feb 2002 08:50: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 IAA21534 for ; Thu, 21 Feb 2002 08:50:14 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16989; Thu, 21 Feb 2002 08:50:11 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1LDoW6Y012483; Thu, 21 Feb 2002 08:50:32 -0500 (EST) Message-ID: <3C74FAF6.10C136F5@dynamicsoft.com> Date: Thu, 21 Feb 2002 08:49:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org, sip@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] updated offer/answer draft 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: 7bit Folks, I've just submitted an update to the offer/answer draft. Until it appears in the archives, you can pick up a copy at: http://www.jdrosen.net/papers/draft-ietf-mmusic-sdp-offer-answer-01.txt This is based on comments received during working group last call, and is the version which will go into IESG last call. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 09:52:31 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 JAA19137 for ; Thu, 21 Feb 2002 09:52:26 -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 JAA26323; Thu, 21 Feb 2002 09:51:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26287 for ; Thu, 21 Feb 2002 09:51:35 -0500 (EST) 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 JAA19130 for ; Thu, 21 Feb 2002 09:51:31 -0500 (EST) Received: from rubin.informatik.uni-bremen.de (IDENT:root@rubin.informatik.uni-bremen.de [134.102.224.59]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with ESMTP id g1LEpNC20835; Thu, 21 Feb 2002 15:51:23 +0100 (MET) From: Joerg Ott Received: (from jo@localhost) by rubin.informatik.uni-bremen.de (8.11.6/8.8.7) id g1LEpN506604; Thu, 21 Feb 2002 15:51:23 +0100 Message-Id: <200202211451.g1LEpN506604@rubin.informatik.uni-bremen.de> To: mmusic@ietf.org Date: Thu, 21 Feb 2002 15:51:23 +0100 (MET) Cc: jo@Informatik.Uni-Bremen.DE (Joerg Ott), csp@isi.edu, mankin@isi.edu X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] MMUSIC meeting at 53rd IETF 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 Folks, MMUSIC is scheduled to meet once for a two hour slot in Minneapolis. The current schedule is Monday, 18 March 2002, 1530 - 1730 (but this may still change) We are now starting to put together the agenda. Please direct slot requests to csp@isi.edu and jo@ipdialog.com. Please note that agenda slots are meant for discussion of items on the WG charter or at least candidates for discussion in the working group. Please also note that meeting time is not meant for presentation of ideas but rather for discussing and solving issues. Please also take note of the IETF statement regarding IPR to be found at http://www.ietf.org/meetings/notewell.html The draft agenda and all related documents will be posted soon as http://www.dmn.tzi.org/ietf/mmusic where you can also find past agendas, Internet Drafts, meeting minutes, etc. Thanks, Joerg _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 11:07: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 LAA22294 for ; Thu, 21 Feb 2002 11:07: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 LAA01609; Thu, 21 Feb 2002 11:06:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01539 for ; Thu, 21 Feb 2002 11:06:39 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22260 for ; Thu, 21 Feb 2002 11:06:35 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1LG61j28781; Thu, 21 Feb 2002 10:06:01 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <19H2J8D6>; Thu, 21 Feb 2002 10:06:05 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D2401C4E573@zrc2c009.us.nortel.com> From: "William Janning" To: "'mmusic@ietf.org'" , "'jdrosen@dynamicsoft.com'" Cc: "Sanjoy Sen", "Mary Barnes" Subject: RE: [VoIP-list] FW: [MMUSIC] summarizing discussion on codec plac ement in answer Date: Thu, 21 Feb 2002 10:06:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BAF1.AA0789F0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BAF1.AA0789F0 Content-Type: text/plain; charset="iso-8859-1" I got this but am not currently subscribed to mmusic. I guess I should join. My reply to this discussion thread follows... -----Original Message----- From: Janning, William [NGC:B601:EXCH] Sent: Wednesday, February 20, 2002 2:39 PM To: Sen, Sanjoy [NGC:B692:EXCH]; Audet, Francois [SC2:4K02:EXCH]; McGrath, Tim [NGC:B682:EXCH] Cc: List, VOIP [NCRTP:9999:UNIX]; Barnes, Mary [NGC:B601:EXCH]; Orton, Scott [NGC:B633:EXCH]; Parameswar, Sriram [NGC:B692:EXCH]; Bharatia, Jayshree [RICH2:2H13:EXCH]; Hogg, Chris [MDN05:MA01:EXCH]; Watson, Mark [MDN05:EP10:EXCH]; Stucker, Brian [NGC:B635:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH] Subject: RE: [VoIP-list] FW: [MMUSIC] summarizing discussion on codec plac ement in answer NO is definitely the answer. When "A" sends a request with SDP, it is saying "I CAN do 1,2,3". When "B" responds, it is saying "I WILL do 1, 2, or 3". In reality it makes no sense for "B" to respond with "I WILL do 1 and 2" as practically speaking this would mean B could dynamically switch between receiving codec 1 or 2 at the whim of A, or that B would be able to properly mix 1 & 2 to the transducer. If this is negotiation, then let us CHOOSE. There is an assumption in codec selection that the codec "B" elects to receive is also the one it is sending (so it must pick from "A"'s initial list). This is implied in the SDP protocol because a single media description only negotiates a single codec - there is not provision to identify the send codec from the receive codec. This fact and the above practicality are why NO is the answer with even additional restrictions (B should never reply with multiple codecs). Supporting the codec capability preference for a particular session for clients is completely related to bandwidth management and perceived voice quality - though mostly bandwidth management. If everybody could do G711 or G722, then they would. Period. So if I say I will receive G729, then there's no way I'm going to send G711 or even G723. Likewise I can't say I'll receive G711 (because I have higher download bandwidth) but send G729 (because my upstream is limited). "A" would have no clue I'm doing so because all I replied in my response was G711. There is no such thing as a "send only" or "receive only" codec - codecs always support both encoding/decoding. However if I did want to specify unique send and receive codecs, then the use of two media descriptions could be used as such: v=0 o=user 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user t=104100432 0 m=audio 9900 RTP/AVP 0 c=IN IP4 192.168.0.1 a=rtpmap:0 PCMU/8000 a=ptime:30 a=recvonly m=audio 9902 RTP/AVP 4 18 c=IN IP4 192.168.0.1 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=ptime:10 a=sendonly I would argue that the attributes "sendonly, recvonly, sendrecv" are MANDATORY in messages and reflect the "I WILL" versus "I CAN", though the difference is also identified by "response" versus "request" message. If the originator wanted to tell the far-end that it was receiving already in the request, then it MUST use the recvonly attribute (though this is a security risk - since the originator doesn't know who the far-end is supposed to be, anybody can be sending the originator packets which they'd happily play until the real far-end answers (assuming of course there was no early media established like on a 183). In order to really handle multiple m= lines with the same media type, something like s= lines should also be per media description (or another field added to the m= line to uniquely identify the media description). This would eliminate m= ordering requirements and facilitate better renegotiation management. --------------------------------------------------- Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. It is a security risk for A to receive RTP before it knows about the far-end. "A' should not receive anything until it receives an SDP response. A should not "play" received RTP unless it comes from the address indicated in the far-end's media description (one reason why c= lines should always be per media description, not session description). 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. B can do likewise. Once the Offer-Answer completes, SDP is set until another Offer-Answer is initiated by either side. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. We must clearly delineate when we are broadcasting our capabilities versus when we are choosing for session establishment. At some point in time we have to CHOOSE. Advertising your capabilities should be done via some other mechanism like OPTIONS. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Either : a) secondary codec's are uniquely flagged in the media description for a specific purpose (like 2833), b) multiple m= lines are used and the response is allowed to negotiate in capabilities which would then be responded to in the ACK. For instance: Request : v=0 o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user1 t=104100432 0 m=audio 9900 RTP/AVP 4 18 0 c=IN IP4 192.168.0.1 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=ptime:30 Response : v=0 o=user2 13723311241683545 13723311241683545 IN IP4 192.168.0.2 s=session1 p=+user2 t=104100452 0 m=audio 9800 RTP/AVP 0 c=IN IP4 192.168.0.2 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 9802 RTP/AVP 99 c=IN IP4 192.168.0.2 a=rtpmap:99 RFC2833/8000 a=ptime:10 a=recvonly ACK : (Really just necessary to confirm the change v=0 o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user1 t=104100432 0 m=audio 9900 RTP/AVP 0 c=IN IP4 192.168.0.1 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 9802 RTP/AVP 99 c=IN IP4 0.0.0.0 a=rtpmap:99 RFC2833/8000 a=ptime:10 a=sendonly The latter choice is good in that it can be used for other things as well (e.g. the term party could negotiate in video without having to generate another Offer/Answer exchange) . This would also support the conference server case where it would like to negotiate a separate return stream (e.g. G729 in, G711 out). William Janning Nortel Networks billj@nortelnetworks.com sip:billj@ sipfx .com -----Original Message----- From: Sen, Sanjoy [NGC:B692:EXCH] Sent: Monday, February 18, 2002 11:52 AM Subject: [VoIP-list] FW: [MMUSIC] summarizing discussion on codec placement in answer Importance: High Do we've any opinion on the interpretation of the ANSWER in the SDP Offer/Answer model (please read Jonathan's email below)? I would particularly appreciate some feedback from our codec experts. Sanjoy -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Friday, February 15, 2002 3:32 PM To: mmusic@ietf.org Subject: [MMUSIC] summarizing discussion on codec placement in answer Folks, I wanted to take a moment to summarize where we were in regards to our long thread on interpretation of the codecs in the answer. The purpose of the summarization is to put all the points on the table, and hopefully invite some further comment from folks outside the few thread participants in the few days which remain. ISSUE: A sends an offer to B. That offer, for example, is for a single sendrecv media stream, which lists codecs 1,2 and 3. The answerer, B, responds, and lists codecs 1 and 2. Now, the question is this: can B still send to A using codec 3? Related to that, can B add codecs in the answer, which A can then send with? Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Arguments for NO: 1. The purpose of the O/A model is to agree on shared views of certain session parameters, such as the directionality (send/recv/sendrecv). Codecs fit into that category as well, since you are already required to indicate, in the answer, a set that partially overlaps with the offer. Furthermore, the goal with codecs is to have the same in both directions, generally, so that this would speak to them being a shared state that is negotiated. 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If you go for YES, there may be interop issues. The converse is not true, of course. 3. It is very useful to narrow down the codec sets in the answer, and we should not always require an extra exchange of O/A just to do that. I took a private poll amongst some implementors. The initial results showed that most assumed the YES case. Some more mails since then indicate its a bit more split, although I think somewhat in favor of YES still. I am somewhat on the fence; I think NO is more correct based on offer/answer, although YES would be the SDP purist view. What I really want is more opinions on this one.... THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C1BAF1.AA0789F0 Content-Type: text/html; charset="iso-8859-1" FW: [MMUSIC] summarizing discussion on codec placement in answer
I got this but am not currently subscribed to mmusic. I guess I should join. My reply to this discussion thread follows...
-----Original Message-----
From: Janning, William [NGC:B601:EXCH]
Sent: Wednesday, February 20, 2002 2:39 PM
To: Sen, Sanjoy [NGC:B692:EXCH]; Audet, Francois [SC2:4K02:EXCH]; McGrath, Tim [NGC:B682:EXCH]
Cc: List, VOIP [NCRTP:9999:UNIX]; Barnes, Mary [NGC:B601:EXCH]; Orton, Scott [NGC:B633:EXCH]; Parameswar, Sriram [NGC:B692:EXCH]; Bharatia, Jayshree [RICH2:2H13:EXCH]; Hogg, Chris [MDN05:MA01:EXCH]; Watson, Mark [MDN05:EP10:EXCH]; Stucker, Brian [NGC:B635:EXCH]; Taylor, Tom-PT [CAR:B800:EXCH]
Subject: RE: [VoIP-list] FW: [MMUSIC] summarizing discussion on codec plac ement in answer

NO is definitely the answer.
 
When "A" sends a request with SDP, it is saying "I CAN do 1,2,3". When "B" responds, it is saying "I WILL do 1, 2, or 3". In reality it makes no sense for "B" to respond with "I WILL do 1 and 2" as practically speaking this would mean B could dynamically switch between receiving codec 1 or 2 at the whim of A, or that B would be able to properly mix 1 & 2 to the transducer. If this is negotiation, then let us CHOOSE.
 
There is an assumption in codec selection that the codec "B" elects to receive is also the one it is sending (so it must pick from "A"'s initial list). This is implied in the SDP protocol because a single media description only negotiates a single codec - there is not provision to identify the send codec from the receive codec. This fact and the above practicality are why NO is the answer with even additional restrictions (B should never reply with multiple codecs).
 
Supporting the codec capability preference for a particular session for clients is completely related to bandwidth management and perceived voice quality - though mostly bandwidth management. If everybody could do G711 or G722, then they would. Period. So if I say I will receive G729, then there's no way I'm going to send G711 or even G723. Likewise I can't say I'll receive G711 (because I have higher download bandwidth) but send G729 (because my upstream is limited). "A" would have no clue I'm doing so because all I replied in my response was G711.
 
There is no such thing as a "send only" or "receive only" codec - codecs always support both encoding/decoding. However if I did want to specify unique send and receive codecs, then the use of two media descriptions could be used as such:
 
v=0
o=user 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=recvonly
m=audio 9902 RTP/AVP 4 18
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=ptime:10
a=sendonly
 
I would argue that the attributes "sendonly, recvonly, sendrecv" are MANDATORY in messages and reflect the "I WILL" versus "I CAN", though the difference is also identified by "response" versus "request" message. If the originator wanted to tell the far-end that it was receiving already in the request, then it MUST use the recvonly attribute (though this is a security risk - since the originator doesn't know who the far-end is supposed to be, anybody can be sending the originator packets which they'd happily play until the real far-end answers (assuming of course there was no early media established like on a 183).
 
In order to really handle multiple m= lines with the same media type, something like s= lines should also be per media description (or another field added to the m= line to uniquely identify the media description). This would eliminate m= ordering requirements and facilitate better renegotiation management.
 
---------------------------------------------------

Arguments for YES:

1. A needs to be prepared to receive with codec 3 once it sends the
offer anyway.

It is a security risk for A to receive RTP before it knows about the far-end. "A' should not receive anything until it receives an SDP response. A should not "play" received RTP unless it comes from the address indicated in the far-end's media description (one reason why c= lines should always be per media description, not session description).


2. If A wants to restrict the set based on the answer, it can always
generate a new offer with a reduced set of codecs.

B can do likewise. Once the Offer-Answer completes, SDP is set until another Offer-Answer is initiated by either side.


3. SDP has always been interpreted as indicating your own capabilities,
and is therefore an "advertisement" that sticks until updated.

We must clearly delineate when we are broadcasting our capabilities versus when we are choosing for session establishment. At some point in time we have to CHOOSE. Advertising your capabilities should be done via some other mechanism like OPTIONS.


4. There are useful cases for adding codecs in the answer, particularly,
support for rfc2833. Thus, lets say A is an end user which can send rfc
2833, but not receive it. So, when it sends an INVITE, it doesn't
include rfc2833 in the INVITE. The server that responds is a media
server, which supports rfc2833. So, it includes it in the answer. Now, A
can actually send with it during the middle of the session, and it will
never receive it (since it didn't advertise it). This provides a useful
function that would otherwise require FID.

Either : a) secondary codec's are uniquely flagged in the media description for a specific purpose (like 2833), b) multiple m= lines are used and the response is allowed to negotiate in capabilities which would then be responded to in the ACK. For instance:

Request :

v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 4 18 0
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=ptime:30
Response :
v=0
o=user2 13723311241683545 13723311241683545 IN IP4 192.168.0.2
s=session1
p=+user2
t=104100452 0
m=audio 9800 RTP/AVP 0
c=IN IP4 192.168.0.2
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 192.168.0.2
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=recvonly
ACK :  (Really just necessary to confirm the change
v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 0.0.0.0
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=sendonly
  
The latter choice is good in that it can be used for other things as well (e.g. the term party could negotiate in video without having to generate another Offer/Answer exchange) . This would also support the conference server case where it would like to negotiate a separate return stream (e.g. G729 in, G711 out).
 
William Janning
Nortel Networks 
-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH]
Sent: Monday, February 18, 2002 11:52 AM
Subject: [VoIP-list] FW: [MMUSIC] summarizing discussion on codec placement in answer
Importance: High

Do we've any opinion on the interpretation of the ANSWER in the SDP Offer/Answer model (please read Jonathan's email below)? I would particularly appreciate some feedback from our codec experts.

Sanjoy


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, February 15, 2002 3:32 PM
To: mmusic@ietf.org
Subject: [MMUSIC] summarizing discussion on codec placement in answer


Folks,

I wanted to take a moment to summarize where we were in regards to our
long thread on interpretation of the codecs in the answer. The purpose
of the summarization is to put all the points on the table, and
hopefully invite some further comment from folks outside the few thread
participants in the few days which remain.

ISSUE:

A sends an offer to B. That offer, for example, is for a single sendrecv
media stream, which lists codecs 1,2 and 3. The answerer, B, responds,
and lists codecs 1 and 2. Now, the question is this: can B still send to
A using codec 3? Related to that, can B add codecs in the answer, which
A can then send with?

Arguments for YES:

1. A needs to be prepared to receive with codec 3 once it sends the
offer anyway.
2. If A wants to restrict the set based on the answer, it can always
generate a new offer with a reduced set of codecs.
3. SDP has always been interpreted as indicating your own capabilities,
and is therefore an "advertisement" that sticks until updated.
4. There are useful cases for adding codecs in the answer, particularly,
support for rfc2833. Thus, lets say A is an end user which can send rfc
2833, but not receive it. So, when it sends an INVITE, it doesn't
include rfc2833 in the INVITE. The server that responds is a media
server, which supports rfc2833. So, it includes it in the answer. Now, A
can actually send with it during the middle of the session, and it will
never receive it (since it didn't advertise it). This provides a useful
function that would otherwise require FID.

Arguments for NO:

1. The purpose of the O/A model is to agree on shared views of certain
session parameters, such as the directionality (send/recv/sendrecv).
Codecs fit into that category as well, since you are already required to
indicate, in the answer, a set that partially overlaps with the offer.
Furthermore, the goal with codecs is to have the same in both
directions, generally, so that this would speak to them being a shared
state that is negotiated.

2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If
you go for YES, there may be interop issues. The converse is not true,
of course.

3. It is very useful to narrow down the codec sets in the answer, and we
should not always require an extra exchange of O/A just to do that.



I took a private poll amongst some implementors. The initial results
showed that most assumed the YES case. Some more mails since then
indicate its a bit more split, although I think somewhat in favor of YES
still.

I am somewhat on the fence; I think NO is more correct based on
offer/answer, although YES would be the SDP purist view. What I really
want is more opinions on this one....

THanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------_=_NextPart_001_01C1BAF1.AA0789F0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 21 22:18: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 WAA10894 for ; Thu, 21 Feb 2002 22:18:55 -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 WAA12735; Thu, 21 Feb 2002 22:18: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 WAA12699 for ; Thu, 21 Feb 2002 22:18:22 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10889 for ; Thu, 21 Feb 2002 22:18:18 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.72]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1M3IX6Y013839; Thu, 21 Feb 2002 22:18:34 -0500 (EST) Message-ID: <3C75B857.741EC919@dynamicsoft.com> Date: Thu, 21 Feb 2002 22:17:43 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Ott CC: mmusic@ietf.org, csp@isi.edu References: <3C74B6D4.B0A4E5F7@tzi.uni-bremen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Another Offer/answer summary 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 FYI, I had a conversation with Joerg early yesterday morning about this, and the proposal which I sent out is the one reflected in offer-answer-01. Thanks, Jonathan R. Joerg Ott wrote: > > Folks, > > we need to reach closure on this issue fairly shortly. > Having gone through the mailing list discussion, we believe > that we can narrow down Jonathan's summary a bit further > and come up with a concrete proposal to beat up: > > Restating the issue: > > > A sends an offer to B. That offer, for example, is for a single > sendrecv > > media stream, which lists codecs 1,2 and 3. The answerer, B, responds, > > and lists codecs 1 and 2. Now, the question is this: can B still send > to > > A using codec 3? Related to that, can B add codecs in the answer, > which > > A can then send with? > > Let us keep in mind that we are not designing offer/answer for telephony > but that telephony is rather one (maybe not unimportant) special case of > multimedia communications. Let us also keep in mind that we should > optimize for the more common cases but at the same time not lose > generality. And let us not forget that SIP is just *one* customer of > offer/answer. > > Let us assume for a moment that we follow the "NO" proposal (and assume > further that this approach does not break interoperability/backward > compatility): > > 1. This idea allows us to narrow down codecs in an efficient fashion. > > This helps people who do not want to require their implementations > to listen for multiple codecs simultaneously (e.g. because of > limited DSP resources or difficulties in implementing MCUs). > > The counter-argument is that such device need to be able to support > multiple codecs in the beginning anyway because of the race condition > between the answer and the first RTP packet. However, this can be > circumvent this by simply waiting for the answer before accepting > media at the risk of clipping. But people may be able to architected > their network in a way that it does not delay the answer unncessarily > and thus avoid clipping in the first place). Alternatively, they may > guess which type of codec to expect or only load the decoder upon > arrival of the first packet (assuming this is not going to change) at > the expense of some additional delay, etc. > > Looks like there are sufficient alternatives that clipping can be > considered a non-issue. (Please note that if you are doing security > handshakes and QoS preconditions or similar stuff, you are not going > to worry about this type of clipping anyway -- but rather about post- > dial delay.) > > 2. Expanding the codec set can be done by means of an extra offer in > the opposite direction. This is an extra exchange but we would > assume > this to be the less common case (and thus not optimize for it). > > The only application scenario for which this is really needed people > have mentioned so far is DTMF -- more specifically, combining a > sendrecv and an sendonly/recvonly media stream. Please share ideas > for others with us. > > We do acknowledge that this scenario is important and need support. > But we also judge that this is not the common case and need not be > optimized for at all cost if a cleaner solution exists. > > This cleaner solution can be based upon FID. In the simplest case, > A uses FID from the very beginning: > > A ---- INVITE ----> B > a=group:FID 1 2 > m=audio pt=0 > a=mid:1 > m=audio pt=97 > a=rtpmap:97 telephone-events > a=mid:2 > a=sendonly > > and B can then decide whether or not to reject telephone events. > > However, A may or may not understand FID and may or may not indicate > its send capabilities as described above. Then we get the following > simple exchange for A calling B: > > A ---- INVITE ----> B > m=audio pt=0 > > A <--- 200 OK ----- B > m=audio pt=0 > A ---- ACK ----> B > > Now B can indicate its receive caps using FID doing a re-INVITE. > > A <--- INVITE ----- B > a=group:FID 1 2 > m=audio pt=0 > a=mid:1 > m=audio pt=97 > a=rtpmap:97 telephone-events > a=mid:2 > a=recvonly > > ... > > Again, we can properly express the intended semantics. If A does not > support FID it ignores the attributes thus yielding the following > in A's perception: > > A <--- INVITE ----- B > m=audio pt=0 > m=audio pt=97 > a=rtpmap:97 telephone-events > > ... > > This is the alternative that can be pursued without FID (and, at the > same time serves as fallback). According to the rules defined in > offer/answer for local processing of multiple streams of the same > type with one local source or sink, this should just work. The > sender > copies the input to all streams if the data can be mapped (i.e. only > events go across the second media session), the receiver mixes the > the incoming data streams locally as appropriate. In a gateway this > may sometimes mean to locally generate DTMF tones and mix them with > audio signals, sometimes mean to locally sink the DTMF and process > it. > > Jonathan, is this interpretation correct? Is there need for > clarifying > text on this issue regarding offer/answer? > > The major issue to discuss here is whether or not there is an extra > RTT > required for this signaling (or whether other SIP methods can be used > to achieve this more quickly) -- and whether the additional delay > (whatever this may be) is an issue for DTMF. > > Thoughts? > > Is this a viable approach ahead? > > Note that we are not religious about this proposal -- but it seems to be > a > reasonable way ahead taking into account some general design principles. > There may be other ways and if better ones are found, such proposals are > welcome. But they need to be found NOW. > > A small disclaimer in the end: probably we should be taking the more > purist > SDP view (as Jonathan calles the "YES" approach) -- but since SDP is > used > in a way it was not supposed to be anyway the NO method may not cause > too > much *extra* headache. > > Colin and Joerg -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 22 06:22: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 GAA27481 for ; Fri, 22 Feb 2002 06:22:55 -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 GAA14426; Fri, 22 Feb 2002 06:22:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14390 for ; Fri, 22 Feb 2002 06:22:20 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27379; Fri, 22 Feb 2002 06:22:17 -0500 (EST) Message-Id: <200202221122.GAA27379@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, 22 Feb 2002 06:22:17 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-offer-answer-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 --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 : An Offer/Answer Model with SDP Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-mmusic-sdp-offer-answer-01.txt Pages : 26 Date : 21-Feb-02 This document defines a mechanism by which two entities can make use of SDP to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdp-offer-answer-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221155040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-offer-answer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221155040.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 Feb 22 11:15: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 LAA08129 for ; Fri, 22 Feb 2002 11:15:21 -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 LAA02699; Fri, 22 Feb 2002 11:14:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA02625 for ; Fri, 22 Feb 2002 11:14:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08091; Fri, 22 Feb 2002 11:14:00 -0500 (EST) Message-Id: <200202221614.LAA08091@ietf.org> To: IETF-Announce: ; Cc: sip@ietf.org, mmusic@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Fri, 22 Feb 2002 11:13:59 -0500 Subject: [MMUSIC] Last Call: SIP: Session Initiation Protocol to Proposed 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 The IESG has received a request from the Session Initiation Protocol Working Group and the Multiparty Multimedia Session Control Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o SIP: Session Initiation Protocol o Reliability of Provisional Responses in SIP o SIP: Locating SIP Servers o SIP-Specific Event Notification o An Offer/Answer Model with SDP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-08.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-100rel-05.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-05.txt http://www.ietf.org/internet-drafts/draft-ietf-sip-events-03.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-offer-answer-01.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 22 14:02: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 OAA16989 for ; Fri, 22 Feb 2002 14:02:38 -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 OAA16297; Fri, 22 Feb 2002 14:02:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16248 for ; Fri, 22 Feb 2002 14:02:12 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16971; Fri, 22 Feb 2002 14:02:09 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1MJ27h23200; Fri, 22 Feb 2002 13:02:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MJ26h18617; Fri, 22 Feb 2002 13:02:07 -0600 (CST) Received: from lmf.ericsson.se (rmt160139.am.ericsson.se [138.85.160.139]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA08779; Fri, 22 Feb 2002 13:02:04 -0600 (CST) Message-ID: <3C769D54.C3B4923A@lmf.ericsson.se> Date: Fri, 22 Feb 2002 21:34:44 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip , mmusic CC: "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Removing security preconditions from manyfolks 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, we are thinking of removing security preconditions from manyfolks. Right now manyfolks handles QoS and security preconditions. However, with MIKEY, this feature seems useless to establish secure channels. If somebody thinks that removing security preconditions from manyfolks is a bad idea, please speak up. Regards, Gonzalo -- Gonzalo Camarillo Phone : +1 212 939 71 71 Columbia University Mobile: +358 40 702 35 35 472 Computer Science Building Fax : +358 9 299 30 52 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo New York, NY 10027 USA Gonzalo.Camarillo@ericsson.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Feb 22 16:35: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 QAA26423 for ; Fri, 22 Feb 2002 16:35:55 -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 QAA28097; Fri, 22 Feb 2002 16:35:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28064 for ; Fri, 22 Feb 2002 16:35:29 -0500 (EST) Received: from mail2.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26411 for ; Fri, 22 Feb 2002 16:35:25 -0500 (EST) DATE: 22 Feb 2002 21:35:26 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 22 Feb 2002 21:35:27 Message-ID: X-Mailer: mail2.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: , Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA28065 Subject: [MMUSIC] Using 0.0.0.0 for placing a call on hold 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 I think, we should specify, that the port for the stream which was put on hold using "0.0.0.0" address should be an arbitrary non-zero value in order for it not to be confused with removed streams. Additionally, note about using "0.0.0.0" address in initial offer should probably belong to 5.1 and not 8.4. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Feb 23 09:56: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 JAA20479 for ; Sat, 23 Feb 2002 09:56: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 JAA16303; Sat, 23 Feb 2002 09:55:22 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA16241 for ; Sat, 23 Feb 2002 09:55:19 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20475 for ; Sat, 23 Feb 2002 09:55:16 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1NEsk314829 for ; Sat, 23 Feb 2002 08:54:46 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 23 Feb 2002 08:54:45 -0600 Message-ID: <23BDB0046F3ED51185CD0002A5608D2401C4E57B@zrc2c009.us.nortel.com> From: "William Janning" To: "'mmusic@ietf.org'" Subject: RE:[MMUSIC] Mulit-codec Response Offer/Answer Issue Date: Sat, 23 Feb 2002 08:26:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BC76.13BC39B0" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BC76.13BC39B0 Content-Type: text/plain; charset="iso-8859-1" This is re: Jonathan Rosenberg's question on codec selection. This may be a double post (I'm not sure it got through the first time) ----------------------------------------------- NO is definitely the answer. When "A" sends a request with SDP, it is saying "I CAN do 1,2,3". When "B" responds, it is saying "I WILL do 1, 2, or 3". In reality it makes no sense for "B" to respond with "I WILL do 1 and 2" as practically speaking this would mean B could dynamically switch between receiving codec 1 or 2 at the whim of A, or that B would be able to properly mix 1 & 2 to the transducer. If this is negotiation, then let us CHOOSE. There is an assumption in codec selection that the codec "B" elects to receive is also the one it is sending (so it must pick from "A"'s initial list). This is implied in the SDP protocol because a single media description only negotiates a single codec - there is not provision to identify the send codec from the receive codec. This fact and the above practicality are why NO is the answer with even additional restrictions (B should never reply with multiple codecs). Supporting the codec capability preference for a particular session for clients is completely related to bandwidth management and perceived voice quality - though mostly bandwidth management. If everybody could do G711 or G722, then they would. Period. So if I say I will receive G729, then there's no way I'm going to send G711 or even G723. Likewise I can't say I'll receive G711 (because I have higher download bandwidth) but send G729 (because my upstream is limited). "A" would have no clue I'm doing so because all I replied in my response was G711. There is no such thing as a "send only" or "receive only" codec - codecs always support both encoding/decoding. However if I did want to specify unique send and receive codecs, then the use of two media descriptions could be used as such: v=0 o=user 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user t=104100432 0 m=audio 9900 RTP/AVP 0 c=IN IP4 192.168.0.1 a=rtpmap:0 PCMU/8000 a=ptime:30 a=recvonly m=audio 9902 RTP/AVP 4 18 c=IN IP4 192.168.0.1 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=ptime:10 a=sendonly I would argue that the attributes "sendonly, recvonly, sendrecv" are MANDATORY in messages and reflect the "I WILL" versus "I CAN", though the difference is also identified by "response" versus "request" message. If the originator wanted to tell the far-end that it was receiving already in the request, then it MUST use the recvonly attribute (though this is a security risk - since the originator doesn't know who the far-end is supposed to be, anybody can be sending the originator packets which they'd happily play until the real far-end answers (assuming of course there was no early media established like on a 183). In order to really handle multiple m= lines with the same media type, something like s= lines should also be per media description (or another field added to the m= line to uniquely identify the media description). This would eliminate m= ordering requirements and facilitate better renegotiation management. Maybe FID helps here (I need to understand the purpose of FID better). --------------------------------------------------- Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. It is a security risk for A to receive RTP before it knows about the far-end. "A' should not receive anything until it receives an SDP response. A should not "play" received RTP unless it comes from the address indicated in the far-end's media description (one reason why c= lines should always be per media description, not session description). 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. B can do likewise. Once the Offer-Answer completes, SDP is set until another Offer-Answer is initiated by either side. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. We must clearly delineate when we are broadcasting our capabilities versus when we are choosing for session establishment. At some point in time we have to CHOOSE. Advertising your capabilities should be done via some other mechanism like OPTIONS. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Either : a) secondary codec's are uniquely flagged in the media description for a specific purpose (like 2833), b) multiple m= lines are used and the response is allowed to negotiate in capabilities which would then be responded to in the ACK. For instance: Request : v=0 o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user1 t=104100432 0 m=audio 9900 RTP/AVP 4 18 0 c=IN IP4 192.168.0.1 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=rtpmap:0 PCMU/8000 a=ptime:30 Response : v=0 o=user2 13723311241683545 13723311241683545 IN IP4 192.168.0.2 s=session1 p=+user2 t=104100452 0 m=audio 9800 RTP/AVP 0 c=IN IP4 192.168.0.2 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 9802 RTP/AVP 99 c=IN IP4 192.168.0.2 a=rtpmap:99 RFC2833/8000 a=ptime:10 a=recvonly ACK : (Really just necessary to confirm the change v=0 o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1 s=session1 p=+user1 t=104100432 0 m=audio 9900 RTP/AVP 0 c=IN IP4 192.168.0.1 a=rtpmap:0 PCMU/8000 a=ptime:30 a=sendrecv m=audio 9802 RTP/AVP 99 c=IN IP4 0.0.0.0 a=rtpmap:99 RFC2833/8000 a=ptime:10 a=sendonly The latter choice is good in that it can be used for other things as well (e.g. the term party could negotiate in video without having to generate another Offer/Answer exchange) . This would also support the conference server case where it would like to negotiate a separate return stream (e.g. G729 in, G711 out). William Janning Nortel Networks billj@nortelnetworks.com sip:billj@ sipfx .com -----Original Message----- From: Sen, Sanjoy [NGC:B692:EXCH] Sent: Monday, February 18, 2002 11:52 AM Subject: FW: [MMUSIC] summarizing discussion on codec placement in answer Importance: High Do we've any opinion on the interpretation of the ANSWER in the SDP Offer/Answer model (please read Jonathan's email below)? I would particularly appreciate some feedback from our codec experts. Sanjoy -----Original Message----- From: Jonathan Rosenberg [ mailto:jdrosen@dynamicsoft.com ] Sent: Friday, February 15, 2002 3:32 PM To: mmusic@ietf.org Subject: [MMUSIC] summarizing discussion on codec placement in answer Folks, I wanted to take a moment to summarize where we were in regards to our long thread on interpretation of the codecs in the answer. The purpose of the summarization is to put all the points on the table, and hopefully invite some further comment from folks outside the few thread participants in the few days which remain. ISSUE: A sends an offer to B. That offer, for example, is for a single sendrecv media stream, which lists codecs 1,2 and 3. The answerer, B, responds, and lists codecs 1 and 2. Now, the question is this: can B still send to A using codec 3? Related to that, can B add codecs in the answer, which A can then send with? Arguments for YES: 1. A needs to be prepared to receive with codec 3 once it sends the offer anyway. 2. If A wants to restrict the set based on the answer, it can always generate a new offer with a reduced set of codecs. 3. SDP has always been interpreted as indicating your own capabilities, and is therefore an "advertisement" that sticks until updated. 4. There are useful cases for adding codecs in the answer, particularly, support for rfc2833. Thus, lets say A is an end user which can send rfc 2833, but not receive it. So, when it sends an INVITE, it doesn't include rfc2833 in the INVITE. The server that responds is a media server, which supports rfc2833. So, it includes it in the answer. Now, A can actually send with it during the middle of the session, and it will never receive it (since it didn't advertise it). This provides a useful function that would otherwise require FID. Arguments for NO: 1. The purpose of the O/A model is to agree on shared views of certain session parameters, such as the directionality (send/recv/sendrecv). Codecs fit into that category as well, since you are already required to indicate, in the answer, a set that partially overlaps with the offer. Furthermore, the goal with codecs is to have the same in both directions, generally, so that this would speak to them being a shared state that is negotiated. 2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If you go for YES, there may be interop issues. The converse is not true, of course. 3. It is very useful to narrow down the codec sets in the answer, and we should not always require an extra exchange of O/A just to do that. I took a private poll amongst some implementors. The initial results showed that most assumed the YES case. Some more mails since then indicate its a bit more split, although I think somewhat in favor of YES still. I am somewhat on the fence; I think NO is more correct based on offer/answer, although YES would be the SDP purist view. What I really want is more opinions on this one.... THanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------_=_NextPart_001_01C1BC76.13BC39B0 Content-Type: text/html; charset="iso-8859-1" FW: [MMUSIC] summarizing discussion on codec placement in answer
This is re: Jonathan Rosenberg's question on codec selection. This may be a double post (I'm not sure it got through the first time)
 
-----------------------------------------------
 
NO is definitely the answer.
 
When "A" sends a request with SDP, it is saying "I CAN do 1,2,3". When "B" responds, it is saying "I WILL do 1, 2, or 3". In reality it makes no sense for "B" to respond with "I WILL do 1 and 2" as practically speaking this would mean B could dynamically switch between receiving codec 1 or 2 at the whim of A, or that B would be able to properly mix 1 & 2 to the transducer. If this is negotiation, then let us CHOOSE.
 
There is an assumption in codec selection that the codec "B" elects to receive is also the one it is sending (so it must pick from "A"'s initial list). This is implied in the SDP protocol because a single media description only negotiates a single codec - there is not provision to identify the send codec from the receive codec. This fact and the above practicality are why NO is the answer with even additional restrictions (B should never reply with multiple codecs).
 
Supporting the codec capability preference for a particular session for clients is completely related to bandwidth management and perceived voice quality - though mostly bandwidth management. If everybody could do G711 or G722, then they would. Period. So if I say I will receive G729, then there's no way I'm going to send G711 or even G723. Likewise I can't say I'll receive G711 (because I have higher download bandwidth) but send G729 (because my upstream is limited). "A" would have no clue I'm doing so because all I replied in my response was G711.
 
There is no such thing as a "send only" or "receive only" codec - codecs always support both encoding/decoding. However if I did want to specify unique send and receive codecs, then the use of two media descriptions could be used as such:
 
v=0
o=user 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=recvonly
m=audio 9902 RTP/AVP 4 18
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=ptime:10
a=sendonly
 
I would argue that the attributes "sendonly, recvonly, sendrecv" are MANDATORY in messages and reflect the "I WILL" versus "I CAN", though the difference is also identified by "response" versus "request" message. If the originator wanted to tell the far-end that it was receiving already in the request, then it MUST use the recvonly attribute (though this is a security risk - since the originator doesn't know who the far-end is supposed to be, anybody can be sending the originator packets which they'd happily play until the real far-end answers (assuming of course there was no early media established like on a 183).
 
In order to really handle multiple m= lines with the same media type, something like s= lines should also be per media description (or another field added to the m= line to uniquely identify the media description). This would eliminate m= ordering requirements and facilitate better renegotiation management. Maybe FID helps here (I need to understand the purpose of FID better). 
 
---------------------------------------------------

Arguments for YES:

1. A needs to be prepared to receive with codec 3 once it sends the
offer anyway.

It is a security risk for A to receive RTP before it knows about the far-end. "A' should not receive anything until it receives an SDP response. A should not "play" received RTP unless it comes from the address indicated in the far-end's media description (one reason why c= lines should always be per media description, not session description).


2. If A wants to restrict the set based on the answer, it can always
generate a new offer with a reduced set of codecs.

B can do likewise. Once the Offer-Answer completes, SDP is set until another Offer-Answer is initiated by either side.


3. SDP has always been interpreted as indicating your own capabilities,
and is therefore an "advertisement" that sticks until updated.

We must clearly delineate when we are broadcasting our capabilities versus when we are choosing for session establishment. At some point in time we have to CHOOSE. Advertising your capabilities should be done via some other mechanism like OPTIONS.


4. There are useful cases for adding codecs in the answer, particularly,
support for rfc2833. Thus, lets say A is an end user which can send rfc
2833, but not receive it. So, when it sends an INVITE, it doesn't
include rfc2833 in the INVITE. The server that responds is a media
server, which supports rfc2833. So, it includes it in the answer. Now, A
can actually send with it during the middle of the session, and it will
never receive it (since it didn't advertise it). This provides a useful
function that would otherwise require FID.

Either : a) secondary codec's are uniquely flagged in the media description for a specific purpose (like 2833), b) multiple m= lines are used and the response is allowed to negotiate in capabilities which would then be responded to in the ACK. For instance:

Request :

v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 4 18 0
c=IN IP4 192.168.0.1
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=ptime:30
Response :
v=0
o=user2 13723311241683545 13723311241683545 IN IP4 192.168.0.2
s=session1
p=+user2
t=104100452 0
m=audio 9800 RTP/AVP 0
c=IN IP4 192.168.0.2
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 192.168.0.2
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=recvonly
ACK :  (Really just necessary to confirm the change
v=0
o=user1 13723311241683544 13723311241683544 IN IP4 192.168.0.1
s=session1
p=+user1
t=104100432 0
m=audio 9900 RTP/AVP 0
c=IN IP4 192.168.0.1
a=rtpmap:0 PCMU/8000
a=ptime:30
a=sendrecv
m=audio 9802 RTP/AVP 99
c=IN IP4 0.0.0.0
a=rtpmap:99 RFC2833/8000
a=ptime:10
a=sendonly
  
The latter choice is good in that it can be used for other things as well (e.g. the term party could negotiate in video without having to generate another Offer/Answer exchange) . This would also support the conference server case where it would like to negotiate a separate return stream (e.g. G729 in, G711 out).
 
William Janning
Nortel Networks 
-----Original Message-----
From: Sen, Sanjoy [NGC:B692:EXCH]
Sent: Monday, February 18, 2002 11:52 AM
Subject: FW: [MMUSIC] summarizing discussion on codec placement in answer
Importance: High

Do we've any opinion on the interpretation of the ANSWER in the SDP Offer/Answer model (please read Jonathan's email below)? I would particularly appreciate some feedback from our codec experts.

Sanjoy


-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, February 15, 2002 3:32 PM
To: mmusic@ietf.org
Subject: [MMUSIC] summarizing discussion on codec placement in answer


Folks,

I wanted to take a moment to summarize where we were in regards to our
long thread on interpretation of the codecs in the answer. The purpose
of the summarization is to put all the points on the table, and
hopefully invite some further comment from folks outside the few thread
participants in the few days which remain.

ISSUE:

A sends an offer to B. That offer, for example, is for a single sendrecv
media stream, which lists codecs 1,2 and 3. The answerer, B, responds,
and lists codecs 1 and 2. Now, the question is this: can B still send to
A using codec 3? Related to that, can B add codecs in the answer, which
A can then send with?

Arguments for YES:

1. A needs to be prepared to receive with codec 3 once it sends the
offer anyway.
2. If A wants to restrict the set based on the answer, it can always
generate a new offer with a reduced set of codecs.
3. SDP has always been interpreted as indicating your own capabilities,
and is therefore an "advertisement" that sticks until updated.
4. There are useful cases for adding codecs in the answer, particularly,
support for rfc2833. Thus, lets say A is an end user which can send rfc
2833, but not receive it. So, when it sends an INVITE, it doesn't
include rfc2833 in the INVITE. The server that responds is a media
server, which supports rfc2833. So, it includes it in the answer. Now, A
can actually send with it during the middle of the session, and it will
never receive it (since it didn't advertise it). This provides a useful
function that would otherwise require FID.

Arguments for NO:

1. The purpose of the O/A model is to agree on shared views of certain
session parameters, such as the directionality (send/recv/sendrecv).
Codecs fit into that category as well, since you are already required to
indicate, in the answer, a set that partially overlaps with the offer.
Furthermore, the goal with codecs is to have the same in both
directions, generally, so that this would speak to them being a shared
state that is negotiated.

2. Many people have interpreted the SDP/bis/rfc2543 drafts this way. If
you go for YES, there may be interop issues. The converse is not true,
of course.

3. It is very useful to narrow down the codec sets in the answer, and we
should not always require an extra exchange of O/A just to do that.



I took a private poll amongst some implementors. The initial results
showed that most assumed the YES case. Some more mails since then
indicate its a bit more split, although I think somewhat in favor of YES
still.

I am somewhat on the fence; I think NO is more correct based on
offer/answer, although YES would be the SDP purist view. What I really
want is more opinions on this one....

THanks,
Jonathan R.

--
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
jdrosen@dynamicsoft.com                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic

------_=_NextPart_001_01C1BC76.13BC39B0-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Feb 23 15:27: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 PAA23911 for ; Sat, 23 Feb 2002 15:27:49 -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 PAA27760; Sat, 23 Feb 2002 15:27: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 PAA27729 for ; Sat, 23 Feb 2002 15:27:00 -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 PAA23903 for ; Sat, 23 Feb 2002 15:26:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Sat, 23 Feb 2002 12:25:14 -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); Sat, 23 Feb 2002 12:25:13 -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 g1NKPeMZ005957 for ; Sat, 23 Feb 2002 12:25:41 -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 16eije-0003Mw-00 for ; Sat, 23 Feb 2002 12:25:34 -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: Sat, 23 Feb 2002 12:25:34 -0800 X-Spam-Status: No, hits=1.2 required=5.5 tests=NO_REAL_NAME version=2.1 X-UIDL: 0730d08d5fa86938de124b342afcff78 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #24 - 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-477407 ] Transport BNF, ; and unclearities (noreply@sourceforge.net) 2. [ rtspspec-Bugs-477413 ] Transport BNF: mode (noreply@sourceforge.net) 3. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT (noreply@sourceforge.net) 4. [ rtspspec-Bugs-477421 ] When to send response (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 21 Feb 2002 16:44:32 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities Bugs item #477407, was opened at 2001-11-01 23:26 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Transport BNF, ; and unclearities Initial Comment: Page 61, Transport BNF: Should not multicast/unicast be proceeded by a ";"? Is multiple entries of the same type allowed? Are there any requirement on having multicast/unicast first? ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-21 16:44 Message: Logged In: YES user_id=3796 Language inserted: "A transport-spec transport option may only contain one of any given parameter within it. Parameters may be given in any order. Additionally, it may only contain the unicast or multicast transport parameter." Example has been fleshed out as follows: "Below is a usage example, showing a client advertising the capability to handle multicast or unicast, preferring multicast. Since this is a unicast-only stream, the server responds with the proper transport parameters for unicast. C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0 CSeq: 302 Transport: RTP/AVP;multicast;mode="PLAY", RTP/AVP;unicast;client_port=3456-3457;mode="PLAY" S->C: RTSP/1.0 200 OK CSeq: 302 Date: 23 Jan 1997 15:35:06 GMT Session: 47112344 Transport: RTP/AVP;unicast;client_port=3456-3457; server_port=6256-6257;mode="PLAY" ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 16:46 Message: Logged In: YES user_id=437905 RESOLUTION: BNF will require semicolon, no mandated ordering, and example will be added. Question was raised if multiple entries of the same type should be allowed? This question was referred to a new issue. Question was raied if interleave parameters should require paramters? This question was referred to a new issue. ---------------------------------------------------------------------- Comment By: Henning Schulzrinne (hgschulz) Date: 2002-01-09 09:59 Message: Logged In: YES user_id=115926 BNF will be fixed to have semicolon. Ordering doesn't matter. Say before header section that parameter order doesn't matter. Also state that parameters can't be replicated (;port=1;port=2) within the same header instance. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:34 Message: Logged In: YES user_id=3796 Agreed it needs fix. We'll need to sort out the right BNF for this, in such a way that it doesn't break backwards compatibility ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477407&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 21 Feb 2002 17:40:48 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477413 ] Transport BNF: mode Bugs item #477413, was opened at 2001-11-01 23:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Transport BNF: mode Initial Comment: Transport ABNF, mode line, The "=" lacks " around it. There are also unclearities if you could actually have mode=""PLAY","RECORD"" ? ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-21 17:40 Message: Logged In: YES user_id=3796 New BNF: parameter = ";" ( "unicast" | "multicast" ) ... | ";" "mode" "=" mode-spec mode-spec = <"> 1#mode <"> | mode mode = "PLAY" | "RECORD" | token ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-29 18:06 Message: Logged In: YES user_id=3796 RESOLVED (Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html Rework BNF, fixing multiple problems not limited to allow outside quotes, but not inside quotes. Quotes are optional ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:45 Message: Logged In: YES user_id=3796 First issue is a thinko, and just needs to be fixed. The BNF is pretty sloppy the way that it is, and needs to be fixed ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477413&group_id=23194 --__--__-- Message: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 21 Feb 2002 18:06:24 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT Bugs item #477416, was opened at 2001-11-01 23:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: BNF error section 3.6 NPT Initial Comment: BNF definition:npt-range, sec 3.6 lacks "npt=" in the begining of the definition. Compare with smpte-range or utc-range. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-21 18:06 Message: Logged In: YES user_id=3796 Fixed in CVS: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rtspspec/parameters.tex.diff?r1=1.4&r2=1.5 ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 16:49 Message: Logged In: YES user_id=437905 RESOLUTION: Require npt=, but have backwards-compatibility note in specificaton. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:53 Message: Logged In: YES user_id=3796 Hmmm...do implementors predominantly implement from the BNF, or from the numerous examples? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477416&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Thu, 21 Feb 2002 19:00:27 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477421 ] When to send response Bugs item #477421, was opened at 2001-11-01 23:43 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&group_id=23194 Category: None >Group: Fixed in CVS/Need WG Approval Status: Open Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: When to send response Initial Comment: Server can't respond to a bad request if no sequence number is present in the request. Resulting in that the client does not know that the server has received it and has issues. Please clarify when a server is allowed to send response to bad request. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-02-21 19:00 Message: Logged In: YES user_id=3796 Added the following section as a new 11.3.1 11.3.1 400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications [H10.4.1]. If the request does not have a CSeq header, the server MUST not include a CSeq in the response. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-02-12 17:10 Message: Logged In: YES user_id=437905 RESOLVED: The Server is allowed to send an immediate response with no sequence number. As a general rule the server should NOT set sequence numbers. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 10:01 Message: Logged In: YES user_id=3796 This one is going to be up to the server. It can send "Connection: close" if the state machine is too messed up (though see #492546 for another discussion). We can't overspecify this, though. Please suggest text to insert in the specification. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477421&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 Mon Feb 25 00:43:06 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 AAA22765 for ; Mon, 25 Feb 2002 00:43: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 AAA17529; Mon, 25 Feb 2002 00:42: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 AAA17485 for ; Mon, 25 Feb 2002 00:42:27 -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 AAA22757; Mon, 25 Feb 2002 00:42:25 -0500 (EST) Received: from nisser.cisco.com (nisser.cisco.com [171.71.176.85]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g1P5fkw12442; Sun, 24 Feb 2002 21:41:46 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id VAA15919; Sun, 24 Feb 2002 21:41:44 -0800 (PST) Message-ID: <3C79CE9B.569814EC@cisco.com> Date: Mon, 25 Feb 2002 00:41:47 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gonzalo Camarillo CC: sip , mmusic , "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com References: <3C769D54.C3B4923A@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: [Sip] Removing security preconditions from manyfolks 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 Not all media streams use RTP or SRTP, and there are other security mechanism than MIKEY. While I don't feel strongly about keeping the "security" precondition, I don't see much gained from removing it. Perhaps more importantly, since you are going to break the existing manyfolks-03 draft mechanism anyway, it would make sense to make the preconditions extensible (with suitable IANA registration procedures of course). -- Flemming Gonzalo Camarillo wrote: > Hi, > > we are thinking of removing security preconditions from manyfolks. Right > now manyfolks handles QoS and security preconditions. However, with > MIKEY, this feature seems useless to establish secure channels. > > If somebody thinks that removing security preconditions from manyfolks > is a bad idea, please speak up. > > Regards, > > Gonzalo > -- > Gonzalo Camarillo Phone : +1 212 939 71 71 > Columbia University Mobile: +358 40 702 35 35 > 472 Computer Science Building Fax : +358 9 299 30 52 > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > New York, NY 10027 > USA Gonzalo.Camarillo@ericsson.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 25 12:10: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 MAA19143 for ; Mon, 25 Feb 2002 12:10:51 -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 MAA04157; Mon, 25 Feb 2002 12:04: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 MAA04114 for ; Mon, 25 Feb 2002 12:04:33 -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 MAA18784 for ; Mon, 25 Feb 2002 12:02:00 -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 g1PH1Ue17763 for ; Mon, 25 Feb 2002 18:01:30 +0100 (MET) Received: from alcatel.be ([138.203.33.40]) by bemail04.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002022518012824:1696 ; Mon, 25 Feb 2002 18:01:28 +0100 Message-ID: <3C7A6DDC.EF266875@alcatel.be> Date: Mon, 25 Feb 2002 18:01:17 +0100 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 02/25/2002 18:01:28, Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 02/25/2002 18:01:29, Serialize complete at 02/25/2002 18:01:29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MMUSIC] new draft on QoS extensions for SDPng 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, We submitted recently a new draft proposing QoS extensions for SDPng. We would very much appreciate the groups feeling and comments on this draft. The draft is available at: http://search.ietf.org/internet-drafts/draft-bos-mmusic-sdpng-qos-00.txt Abstract: This document describes a framework that allows end-users/applications to inform each other and negotiate about the QoS characteristics of the media components in a session, prior to its establishment. The QoS negotiation is modeled after the existing codec negotiation and as such becomes an integral part of the existing SDPng Offer/Answer model. The QoS information is exchanged at session set-up time using two new types of SDPng extensions between the end-users sites. Apart from the end hosts also some authorized intermediate proxies controlling the session set-up MAY participate to the QoS negotiation. Secondly this document proposes SDPng extensions which allow the end-user to request an ordered list of preferred QoS levels per media stream during the QoS negotiation. The first type of extensions, called TI (Traffic Information), characterizes the traffic type of the bearer associated with the media stream. TI is typically related to bandwidth and packet size. The second type of extensions, called SI (Sensitivity Information), characterizes the sensitivity level of the service requested by the end-user with respect to the QoS information carried in the first type of SDPng extensions. SI is typically related to delay, jitter and packet loss. Regards, Suresh _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 25 17:15:43 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 RAA01835 for ; Mon, 25 Feb 2002 17:15:43 -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 RAA21401; Mon, 25 Feb 2002 17:12:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21358 for ; Mon, 25 Feb 2002 17:12:40 -0500 (EST) Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01777; Mon, 25 Feb 2002 17:12:36 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id g1PMBm826379; Mon, 25 Feb 2002 17:11:48 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 16:11:43 -0600 Message-ID: <70565611B164D511957A001083FCDD5601870100@VA02> From: "Peterson, Jon" To: "'Flemming Andreasen'" , Gonzalo Camarillo Cc: sip , mmusic , "Fredrik Lindholm (ERA)" , Jonathan Rosemberg , wtm@research.att.com Date: Mon, 25 Feb 2002 16:11:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: [Sip] Removing security preconditions from manyfolks 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 One of the reasons why you need a special preconditions flag (and the rest of the manyfolks apparatus) for QoS is because you use a separate protocol (like RSVP) to negotiate the reserved path end-to-end. Nothing about SIP or SDP or RTP would otherwise tell you that reservation of the path has been expected or achieved. IMHO, this would be unwise, and probably infeasible, for a security mechanism. The use of sRTP e2e will be obvious to the respective user agents, for example, and the parameters of the sRTP session should be correlated easily to information in SDP or SIP so the UAs can have verifiable expectations about the session's security. I think all e2e media security mechanisms will probably need to have these sorts of properties (regardless of whether or not you use RTP, secure media will still be secured, and that will always be obvious to the user agents). Therefore, I think that a separate preconditions flag for security should always be superfluous for any useful security mechanism. I think we can ditch it. That much said, I don't necessarily oppose the IANA registration suggested by Flemming below, although I think as a motivation for it we'd need to understand, generally speaking, what sort of other preconditions people might find desirable. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Sunday, February 24, 2002 9:42 PM > To: Gonzalo Camarillo > Cc: sip; mmusic; Fredrik Lindholm (ERA); Jonathan Rosemberg; > wtm@research.att.com > Subject: Re: [Sip] Removing security preconditions from manyfolks > > > Not all media streams use RTP or SRTP, and there are other security > mechanism than MIKEY. While I don't feel strongly about keeping the > "security" precondition, I don't see much gained from removing it. Perhaps > more importantly, since you are going to break the existing manyfolks-03 > draft mechanism anyway, it would make sense to make the preconditions > extensible (with suitable IANA registration procedures of course). > > -- Flemming > > > Gonzalo Camarillo wrote: > > > Hi, > > > > we are thinking of removing security preconditions from > manyfolks. Right > > now manyfolks handles QoS and security preconditions. However, with > > MIKEY, this feature seems useless to establish secure channels. > > > > If somebody thinks that removing security preconditions > from manyfolks > > is a bad idea, please speak up. > > > > Regards, > > > > Gonzalo > > -- > > Gonzalo Camarillo Phone : +1 212 939 71 71 > > Columbia University Mobile: +358 40 702 35 35 > > 472 Computer Science Building Fax : +358 9 299 30 52 > > 1214 Amsterdam Ave., Mail Code 0401 http://www.hut.fi/~gonzalo > > New York, NY 10027 > > USA Gonzalo.Camarillo@ericsson.com > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > -- > Flemming Andreasen > Cisco Systems > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Feb 25 20:48: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 UAA05861 for ; Mon, 25 Feb 2002 20:48:54 -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 UAA00629; Mon, 25 Feb 2002 20:48:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA00598 for ; Mon, 25 Feb 2002 20:48:11 -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 UAA05855 for ; Mon, 25 Feb 2002 20:48:07 -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 g1Q1lktC010092 for ; Mon, 25 Feb 2002 17:47:46 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g1Q1ljMa003409 for ; Mon, 25 Feb 2002 17:47:45 -0800 Date: Mon, 25 Feb 2002 17:47:38 -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] Minutes from February 20 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 Hi all, Here are the minutes from last week's RTSP telecon: http://rtsp.org/2002/telecon/minutes20Feb.html They're also included below. Enjoy! Rob ---- Rtsp Tc Minutes20 Feb2002 ------------------------------------------------------------------------ 1. Administrivia <#line3> 1. Attendees <#line5> 2. Meeting in Minneapolis <#line22> 2. Issue discussion <#line28> 1. 477428 <#line30> 2. 483356 <#line41> 3. 493270 <#line83> 4. 506412 <#line94> Administrivia Attendees * Milko Boic * Magnus Westerlund * Rob Lanphier * Jonathan Sergent * Anders Klemets * Colin Perkins * Joerg Ott * Sean Sheedy * Aravind Narasimhan * Tom Marshall * Thomas Zeng * Jeff Ayars Agenda: http://rtsp.org/2002/telecon/agenda20Feb.html Meeting in Minneapolis MMUSIC meets on Monday. BOF - Tentatively Tuesday, Rob to look into room (lunch) Issue discussion 477428 * http://rtsp.org/bug477428 * JS: I think it's not allowed * MW: Did you see my state machine? * RL: (notes not many have grokked it) * JS: Not legal per previous resolution * MW: agreed RESOLUTION: not allowed, as per point a of email 483356 http://rtsp.org/bug483356 * JS: Use of "*" doesn't seem right given proxies * TM: proxy will use session * JA: Use agg url, short of that, use "base" url, short of that, use session * JS: some servers allow arbitrary aggregation * JA: seems pretty cavalier for a client to assume that this is legal * JS: if agg control, then the URL doesn't necessarily have any semantics * JS: how does one validate that URL? * TM: can play message be sent with multiple session ids * JS: session not defined as multi-value feature * JA: perfectly happy without relying on play URL * JA: don't like "*" * JS: Could specifically say that servers shouldn't try to validate URL * RL: url strictly informative * JS: server SHOULD not validate url * MW: we should disallow the media URL * RL: what does a server allow and what not? * JS: can say client should use presentation URL * AK: presentation URL from first session created will be what the play URL is * RL: how about a bunch of shoulds (including recommendation for logging) * JA: can't trust PLAY url anyway * TZ: it's ok to use the first SDP * JS: are server writers out ahead of client writers? * JA: yes * TZ: multiple urls in play request? * JS: not allowed by grammer * JA: how about host/sessionid * JS: client aggregation is not the norm, and we shouldn't optimize for it * TZ: seem to be shutting down future opportunites * JS: you want to report presentation url * AN: we should consider adding a method called COMPOSE or having an initial SETUP to negotiate the presentation URL with the server for a given session, especially if the session is going to aggregate stream URLs from multiple sources. * RL: possible resolution? client SHOULD send the presentation URL as defined by session description; server MAY refuse play request if presentation URL doesn't match * RL: how about a client aggregation require tag? * AK: session header is optional * TM: (reads spec) * JS: have informative note explaining why it's not a must; explain that only when not possible, not when not convenient * RESOLVED: client SHOULD send the presentation URL as defined by session description; server MAY refuse play request if presentation URL doesn't match. Have informative note explaining why it's not a must; explain that only when not possible, not when not convenient * ACTION ITEM (no owner yet): put together feature tag proposal for client agg 493270 * http://rtsp.org/bug493270 * RESOLVED: this is solved in MUTE/UNMUTE proposal * TZ: name MUTE has audio connotations * JS: means that when resumes (UNMUTE) that synch is maintained * JA: waht about PAUSE * JS: PAUSE should be same as PLAY * TM: does server have to fail * RL: no....just has the option * JS: it can be bw compat 506412 * http://rtsp.org/bug506412 * JS: allows TEARDOWN on individual streams * MW: tear down all media session goes away * JS: it only invalidates the session id if the presentation url is used in TEARDOWN * MW: could disallow in PLAY state * JS: what is that useful for? * JA: language track switching * AJ: language tracks useful * JS: spec not clear if setup new url while playing * MW: state machine is currently insufficient anyway * JA: because we have MUTE/UNMUTE, and because we have mixing of agg/no agg control, it's hard to get back into ready state * JA: disallow in PLAY state, but allow in READY state * RL: perhaps we need an option tag * RL: server may refuse * RESOLUTION: client MAY send TEARDOWN of stream URL. Server MAY refuse. Need proposal for option negotiation. When Server refuses, MUST return "method not allowed in this state" with proper Allow header * MW: need to clarify when session goes away * AK: but then client may not know how to cope * JS: must use presentation url * TZ: Treat TEARDOWN as method to relinquish the session ID * JS: should we depart from current RFC for this * AK: client may not expect session to go away * JS: client should be prepared to not get a session id back, and that's the signal that it's gone * TZ: how about having the * for teardown * RL: how about allow * or presentation url for session teardown * RESOLVED: allow * or presentation url for session teardown * OPEN ISSUE: per media stream URLs, what does teardown mean? _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 26 15:39: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 PAA20666 for ; Tue, 26 Feb 2002 15:39: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 PAA18588; Tue, 26 Feb 2002 15:39:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA18553 for ; Tue, 26 Feb 2002 15:39:19 -0500 (EST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20652 for ; Tue, 26 Feb 2002 15:39:15 -0500 (EST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1QKcia03514; Tue, 26 Feb 2002 14:38:44 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 14:38:44 -0600 Message-ID: <1B54FA3A2709D51195C800508BF9386A0311A168@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'jari.arkko@ericsson.com'" , "'elisabetta.carrara@era.ericsson.se'" , "'fredrik.lindholm@era.ericsson.se'" Cc: "'mmusic@ietf.org'" Subject: FW: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt Date: Tue, 26 Feb 2002 14:38:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BF05.955A2860" 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1BF05.955A2860 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF05.955A2860" ------_=_NextPart_001_01C1BF05.955A2860 Content-Type: text/plain; charset="iso-8859-1" Hi, I have a question/comment reqarding the I-D in e-mail below. Section 2.1 states that "where safe and byte-string are as defined in SDP [SDP]" regarding usage of the new SDP attributes: keymgmt-data = "keymgmt-data: " byte-string key-extra-auth = "keymgmt-auth:" byte-string In RFC 2327 "SDP: Session Description Protocol", "byte-string" is defined as: text = byte-string ;default is to interpret this as IS0-10646 UTF8 ;ISO 8859-1 requires a "a=charset:ISO-8859-1" ;session-level attribute to be used Since this data can be encrypted, shouldn't the parameter be "base64 encoded data" instead (perhaps I am missing something)? See Section 6.0 of "MIKEY: Multimedia Internet KEYing" where a specific example is given (I cut and paste from that I-D below): a=keymgmt-data: Also, I'm not sure about the usage of "safe" in the SDPbis I-D (see "SDP" Session Description Protocol". Regards, Pete -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, February 21, 2002 6:02 AM Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt 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-02.txt Pages : 11 Date : 20-Feb-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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-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-kmgmt-ext-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-kmgmt-ext-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_001_01C1BF05.955A2860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [MMUSIC] I-D = ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt

Hi,

I have a question/comment reqarding the I-D in e-mail = below.

Section 2.1 states that "where safe and = byte-string are as defined in SDP [SDP]" regarding usage of the = new SDP attributes:

keymgmt-data   =3D "keymgmt-data: = " byte-string
key-extra-auth =3D "keymgmt-auth:" = byte-string

In RFC 2327 "SDP: Session Description = Protocol", "byte-string" is defined as:

text = =3D           &nb= sp;       byte-string
          &nb= sp;           &nb= sp;  ;default is to interpret this as IS0-10646 UTF8
          &nb= sp;           &nb= sp;  ;ISO 8859-1 requires a = "a=3Dcharset:ISO-8859-1"
          &nb= sp;           &nb= sp;  ;session-level attribute to be used

Since this data can be encrypted, shouldn't the = parameter be "base64 encoded data" instead (perhaps I am = missing something)? See Section 6.0 of = <draft-ietf-msec-mikey-00.txt> "MIKEY: Multimedia Internet = KEYing" where a specific example is given (I cut and paste from = that I-D below):

     a=3Dkeymgmt-data:<base64 = encoded data>

Also, I'm not sure about the usage of = "safe" in the SDPbis I-D (see = <draft-ietf-mmusic-sdp-new-05.txt> "SDP" Session = Description Protocol".

Regards,

Pete

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Thursday, February 21, 2002 6:02 AM
Cc: mmusic@ietf.org
Subject: [MMUSIC] I-D = ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt


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-02.txt
        Pages           : = 11
        Date    =         : 20-Feb-02
       =20
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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-= kmgmt-ext-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-kmgmt-ext-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-kmgmt-ext-02.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C1BF05.955A2860-- ------_=_NextPart_000_01C1BF05.955A2860 Content-Type: message/rfc822 To: Subject: Date: Thu, 21 Feb 2002 09:22:58 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C1BF05.955A2860" ------_=_NextPart_002_01C1BF05.955A2860 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C1BF05.955A2860" ------_=_NextPart_003_01C1BF05.955A2860 Content-Type: text/plain ------_=_NextPart_003_01C1BF05.955A2860 Content-Type: text/html

  ------_=_NextPart_003_01C1BF05.955A2860-- ------_=_NextPart_002_01C1BF05.955A2860 Content-Type: application/octet-stream; name="ATT86990" Content-Disposition: attachment; filename="ATT86990" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020220135122.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-02.txt ------_=_NextPart_002_01C1BF05.955A2860 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-mmusic-kmgmt-ext-02"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C1BF05.955A2860-- ------_=_NextPart_000_01C1BF05.955A2860-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 26 16:03:33 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 QAA21583 for ; Tue, 26 Feb 2002 16:03:33 -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 QAA20150; Tue, 26 Feb 2002 16:03: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 QAA20115 for ; Tue, 26 Feb 2002 16:03:11 -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 QAA21580 for ; Tue, 26 Feb 2002 16:03:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 26 Feb 2002 13:03:09 -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); Tue, 26 Feb 2002 13:03:08 -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 g1QL0KMZ018502 for ; Tue, 26 Feb 2002 13:00:20 -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 16fohn-0003ww-00 for ; Tue, 26 Feb 2002 13:00:11 -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: Tue, 26 Feb 2002 13:00:11 -0800 X-Spam-Status: No, hits=1.2 required=5.5 tests=NO_REAL_NAME version=2.1 X-UIDL: be30d2f484a7ba0db554773815cb1679 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #25 - 2 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-522602 ] Should Allow S->C "Teardown" (noreply@sourceforge.net) 2. [ rtspspec-Feature Requests-522607 ] Need END_OF_STREAM request (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 25 Feb 2002 11:38:22 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-522602 ] Should Allow S->C "Teardown" Bugs item #522602, was opened at 2002-02-25 11:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=522602&group_id=23194 Category: General Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Rob Lanphier (robla) Summary: Should Allow S->C "Teardown" Initial Comment: Table 2 in section 10 of RFC2326 seem to disallow S->C Teardown. And section 10.7 is vague on whether S->C teardown is OK. This should be relaxed, because Server might have to use TEARDOWN to tell client a live session is over. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=522602&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 25 Feb 2002 11:49:56 -0800 Subject: [rtspspec-bugs] [ rtspspec-Feature Requests-522607 ] Need END_OF_STREAM request Feature Requests item #522607, was opened at 2002-02-25 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377747&aid=522607&group_id=23194 Category: None Group: None Status: Open Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Need END_OF_STREAM request Initial Comment: Currently there is no way for Server to inform Client the completion of a presentation (VOD or Live) without issuing a TEARDOWN and thus release reources. What if the player wants to use the same resources (pertinent to its sessionID) to watch another clip? It would be wasteful to teardown and then acquire another sessionID immediately. Would like to see a END_OF_STREAM method added on the S->C direction. E.g.: END_OF_STREAM or RTSP/1.0 SESSION: REASON: ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377747&aid=522607&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 Tue Feb 26 19:58: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 TAA26690 for ; Tue, 26 Feb 2002 19:58:47 -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 TAA02615; Tue, 26 Feb 2002 19:57:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA02583 for ; Tue, 26 Feb 2002 19:57:24 -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 TAA26671 for ; Tue, 26 Feb 2002 19:57:20 -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 g1R0uwtC013631; Tue, 26 Feb 2002 16:56:58 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g1R0uvMa017088; Tue, 26 Feb 2002 16:56:57 -0800 Date: Tue, 26 Feb 2002 16:56:49 -0800 (Pacific Standard Time) From: Rob Lanphier To: Magnus Westerlund cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine In-Reply-To: <3C73F16C.53818D81@era.ericsson.se> 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 Hi Magnus, This is really good work. Still sifting through the implications here, but one quick question to kick off the conversation: could the "ready-na" state and "paused-na" state be merged (as well as "ready-a" and "paused-a")? I'm not sure there's a useful distinction to be made between these two states. Rob On Wed, 20 Feb 2002, Magnus Westerlund wrote: > Hi again! > > I made some errors in the table and I guess there may be some more still > in there. Anyway, here is a new version. > > RTSP state machine ver. 0.2 > > This state machine does not contain RECORD which needs to be added. > 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. Does not include queued play either. > > 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. > > > States Explanation > ----------------------------------------------------------------------- > Init Initial state no session exist > Ready-na Non aggregated session in Ready state > Playing-na Non aggregated session in Playing state > Paused-na Non aggregated session in Paused state > Ready-a Aggregated session in Ready state > Playing-a Aggregated session in Playing > Paused-a Aggregated session in Pause > > The reason for separating aggregated and non aggregated states are the > following: > - Play and Pause may only be done on aggregate URL and not media URLs > in aggregated control. In non-aggregated the two are the same. > - > > > State variables > --------------- > Nr-media > > State: Init > Action Prerequisite New State Response > ----------------------------------------------------------------------- > SETUP Ready-na Nr-media = 1 > > > State: Ready-na > Action Prerequisite New State Response > ----------------------------------------------------------------------- > SETUP New URL Ready-a Nr-media = 2 > SETUP Present URL Ready-na Change transport param. > Teardown *|media URL Init Ok > PLAY No range Playing-na from beginning of media > PLAY Range Playing-na according to range > Timeout Init > > State: Playing-na > Action Prerequisite New State Response > ----------------------------------------------------------------------- > PAUSE No range Paused-na Set pause point > PAUSE Range > now Playing-na Set pause point > Pause-point reached Paused-na > End of media Ready-na > Timeout Init > SETUP New URL,Allowed? Playing-a Nr-media +=1 > SETUP Present URL, Allowed? Playing-na Change transport param. > TEARDOWN Allowed? Init > > > State: Paused-na > Action Prerequisite New State Response > ----------------------------------------------------------------------- > PLAY No range Playing-na Play from pause point > PLAY Range Playing-na according to range > Timeout Init > SETUP New URL Paused-a Nr-media +=1 > SETUP Present URL Ready-na Change transport param. > TEARDOWN *|media URL Init > > State: Ready-a > Action Prerequisite New State Response > ----------------------------------------------------------------------- > SETUP New URL Ready-a Nr-media +=1 > SETUP Present mediaURL Ready-a Change transport param. > TEARDOWN * | Pres URL Init No session hdr. > TEARDOWN Nr-media >2 Ready-a Nr-media -=1, sess hdr > TEARDOWN Nr-media == 2 Ready-na Nr-media = 1, sess hdr > Timeout Init > PLAY No range,AggURL Playing-a from beginning of media > PLAY Range, Agg URL Playing-a according to range > > > State: Playing-a > Action Prerequisite New State Response > ----------------------------------------------------------------------- > PAUSE No range Paused-a Set pause point > PAUSE Range > now Playing-a Set point to pause at > Pause-point reached Paused-a Set pause point > End of media >=1 Media plays Playing-a > End of media All media ended Ready-a > Timeout Init > SETUP New URL,Allowed? Playing-a Nr-media +=1 > SETUP Present URL,Allowed? Playing-a Change transport param > TEARDOWN *|pres URL Init No session hdr allowed? > TEARDOWN Allowed? Nr-m>2 Playing-a Nr-media -=1, sess hdr > TEARDOWN Allowed? Nr-m=2 Playing-na Nr-media = 1, sess hdr > > > State: Paused-a > Action Prerequisite New State Response > ----------------------------------------------------------------------- > PLAY No range Playing-a Play from pause point > PLAY Range Playing-a according to range > Timeout Init > SETUP New URL Paused-a Nr-media +=1 > SETUP Present URL Paused-a Change transport param. > TEARDOWN *|pres URL Init > TEARDOWN Nr-media >2 Paused-a Nr-media -=1 > TEARDOWN Nr-media == 2 Paused-na Nr-media = 1 > > > > > > 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 > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Feb 26 22:52: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 WAA01273 for ; Tue, 26 Feb 2002 22:52:38 -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 WAA10445; Tue, 26 Feb 2002 22:52:24 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA10412 for ; Tue, 26 Feb 2002 22:52:23 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01260 for ; Tue, 26 Feb 2002 22:52:18 -0500 (EST) Received: from dynamicsoft.com ([63.110.3.2]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g1R3qH6Y018233; Tue, 26 Feb 2002 22:52:18 -0500 (EST) Message-ID: <3C7C57B2.F67FDECD@dynamicsoft.com> Date: Tue, 26 Feb 2002 22:51:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Roman Shpount CC: mmusic@ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Using 0.0.0.0 for placing a call on hold 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 Roman Shpount wrote: > > I think, we should specify, that the port for the stream which was put > on hold using "0.0.0.0" address should be an arbitrary non-zero value in > order for it not to be confused with removed streams. 0.0.0.0 is not recommended for on hold, but I otherwise agree. I added a sentence to that effect. Additionally, note > about using "0.0.0.0" address in initial offer should probably belong to > 5.1 and not 8.4. The idea is not to special case it, and since its usage is not recommended, I would prefer to leave it where it sits. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 04:48: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 EAA15129 for ; Wed, 27 Feb 2002 04:48:19 -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 EAA07091; Wed, 27 Feb 2002 04:47:58 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA07003 for ; Wed, 27 Feb 2002 04:47:53 -0500 (EST) Received: from penguin-ext.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 EAA15121 for ; Wed, 27 Feb 2002 04:47:48 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1R9lpB14348; Wed, 27 Feb 2002 10:47:51 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA17857; Wed, 27 Feb 2002 10:47:50 +0100 Message-ID: <3C7CAB46.A3239E06@era.ericsson.se> Date: Wed, 27 Feb 2002 10:47:50 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Lanphier CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine 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 Rob, In my opinion they have a useful distinction. The different state represent if the point of pausing is valid or not. This is part of the state and it helps clarify behavior regarding pause and play without range. When in ready-na and receiving a play without range it changes state to playing-na and plays from the beginning. When in pause-na and receives the same play it will play from the pause point stored upon entering the pause state. We have had a discussion on this during one of the telecoms. What was raised then was the following. When a play without range is issued in state ready-na it starts from the beginning. When the server reaches the end of the media, what shall it do. My interpretation which is represented in the state machine is that it returns to ready-na, when doing play without range again it will start from the beginning. Another interpretation is that it stays at the end point and any play without range will be accepted but return to ready state directly as it is at the end. This behavior requires a explicit rewind of the media with a play with range 0- to start from the beginning. This is logged as issue #513875 at source forge. Regards Magnus Rob Lanphier wrote: > Hi Magnus, > > This is really good work. Still sifting through the implications here, > but one quick question to kick off the conversation: could the "ready-na" > state and "paused-na" state be merged (as well as "ready-a" and > "paused-a")? I'm not sure there's a useful distinction to be made between > these two states. > > Rob > > On Wed, 20 Feb 2002, Magnus Westerlund wrote: > > > Hi again! > > > > I made some errors in the table and I guess there may be some more still > > in there. Anyway, here is a new version. > > > > RTSP state machine ver. 0.2 > > > > This state machine does not contain RECORD which needs to be added. > > 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. Does not include queued play either. > > > > 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. > > > > > > States Explanation > > ----------------------------------------------------------------------- > > Init Initial state no session exist > > Ready-na Non aggregated session in Ready state > > Playing-na Non aggregated session in Playing state > > Paused-na Non aggregated session in Paused state > > Ready-a Aggregated session in Ready state > > Playing-a Aggregated session in Playing > > Paused-a Aggregated session in Pause > > > > The reason for separating aggregated and non aggregated states are the > > following: > > - Play and Pause may only be done on aggregate URL and not media URLs > > in aggregated control. In non-aggregated the two are the same. > > - > > > > > > State variables > > --------------- > > Nr-media > > > > State: Init > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > SETUP Ready-na Nr-media = 1 > > > > > > State: Ready-na > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > SETUP New URL Ready-a Nr-media = 2 > > SETUP Present URL Ready-na Change transport param. > > Teardown *|media URL Init Ok > > PLAY No range Playing-na from beginning of media > > PLAY Range Playing-na according to range > > Timeout Init > > > > State: Playing-na > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > PAUSE No range Paused-na Set pause point > > PAUSE Range > now Playing-na Set pause point > > Pause-point reached Paused-na > > End of media Ready-na > > Timeout Init > > SETUP New URL,Allowed? Playing-a Nr-media +=1 > > SETUP Present URL, Allowed? Playing-na Change transport param. > > TEARDOWN Allowed? Init > > > > > > State: Paused-na > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > PLAY No range Playing-na Play from pause point > > PLAY Range Playing-na according to range > > Timeout Init > > SETUP New URL Paused-a Nr-media +=1 > > SETUP Present URL Ready-na Change transport param. > > TEARDOWN *|media URL Init > > > > State: Ready-a > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > SETUP New URL Ready-a Nr-media +=1 > > SETUP Present mediaURL Ready-a Change transport param. > > TEARDOWN * | Pres URL Init No session hdr. > > TEARDOWN Nr-media >2 Ready-a Nr-media -=1, sess hdr > > TEARDOWN Nr-media == 2 Ready-na Nr-media = 1, sess hdr > > Timeout Init > > PLAY No range,AggURL Playing-a from beginning of media > > PLAY Range, Agg URL Playing-a according to range > > > > > > State: Playing-a > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > PAUSE No range Paused-a Set pause point > > PAUSE Range > now Playing-a Set point to pause at > > Pause-point reached Paused-a Set pause point > > End of media >=1 Media plays Playing-a > > End of media All media ended Ready-a > > Timeout Init > > SETUP New URL,Allowed? Playing-a Nr-media +=1 > > SETUP Present URL,Allowed? Playing-a Change transport param > > TEARDOWN *|pres URL Init No session hdr allowed? > > TEARDOWN Allowed? Nr-m>2 Playing-a Nr-media -=1, sess hdr > > TEARDOWN Allowed? Nr-m=2 Playing-na Nr-media = 1, sess hdr > > > > > > State: Paused-a > > Action Prerequisite New State Response > > ----------------------------------------------------------------------- > > PLAY No range Playing-a Play from pause point > > PLAY Range Playing-a according to range > > Timeout Init > > SETUP New URL Paused-a Nr-media +=1 > > SETUP Present URL Paused-a Change transport param. > > TEARDOWN *|pres URL Init > > TEARDOWN Nr-media >2 Paused-a Nr-media -=1 > > TEARDOWN Nr-media == 2 Paused-na Nr-media = 1 > > > > > > > > -- 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 Feb 27 08:13: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 IAA20584 for ; Wed, 27 Feb 2002 08:13:28 -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 IAA18809; Wed, 27 Feb 2002 08:13:06 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA18780 for ; Wed, 27 Feb 2002 08:13:02 -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 IAA20579 for ; Wed, 27 Feb 2002 08:12:58 -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 g1RDD0Zc009148 for ; Wed, 27 Feb 2002 14:13:00 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Feb 27 13:34:24 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Feb 2002 13:34:29 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE40A3@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Peter Barany'" , "'jari.arkko@ericsson.com'" , "Elisabetta Carrara (ERA)" Cc: "'mmusic@ietf.org'" Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt Date: Wed, 27 Feb 2002 09:19:37 +0100 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, Hi, (comments inline) >I have a question/comment reqarding the I-D in e-mail below. > Section 2.1 states that "where safe and byte-string are as > defined in SDP [SDP]" regarding usage of the new SDP attributes: > > keymgmt-data = "keymgmt-data: " byte-string > key-extra-auth = "keymgmt-auth:" byte-string > In RFC 2327 "SDP: Session Description Protocol", > "byte-string" is defined as: > > text = byte-string > ;default is to interpret this as IS0-10646 UTF8 > ;ISO 8859-1 requires a "a=charset:ISO-8859-1" > ;session-level attribute to be used > Almost ;-) byte-string = 1*(0x01..0x09|0x0b|0x0c|0x0e..0xff) ;any byte except NUL, CR or LF anyway... > Since this data can be encrypted, shouldn't the parameter be > "base64 encoded data" instead (perhaps I am missing something)? I agree that this will be the best way to do it in most solutions. But as this is a framework, I don't think it is good to restrict the encoding of the field too much. Therefore, the encoding of the field is uniquely defined by the key management protocol used (I guess we will need to clarify this). E.g. if MIKEY is used, then the "keymgmt-data" field will be base64 encoded as it is stated that in MIKEY. > See Section 6.0 of "MIKEY: > Multimedia Internet KEYing" where a specific example is given > (I cut and paste from that I-D below): > a=keymgmt-data: > Also, I'm not sure about the usage of "safe" in the SDPbis I-D > (see "SDP" Session Description > Protocol". > That's a good one. It just disapeared :-) Thanks, Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 15:16: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 PAA15200 for ; Wed, 27 Feb 2002 15:16:27 -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 PAA25892; Wed, 27 Feb 2002 15:09:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA25855 for ; Wed, 27 Feb 2002 15:09:51 -0500 (EST) Received: from virago (tog-wakko3.prognet.com [207.188.29.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14888 for ; Wed, 27 Feb 2002 15:09:47 -0500 (EST) Received: from tommy by virago with local (Exim 3.34 #1 (Debian)) id 16gAOZ-0002f2-00; Wed, 27 Feb 2002 12:09:47 -0800 Date: Wed, 27 Feb 2002 12:09:47 -0800 From: Tom Marshall To: Magnus Westerlund Cc: Rob Lanphier , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine Message-ID: <20020227200947.GA10045@real.com> References: <3C7CAB46.A3239E06@era.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7CAB46.A3239E06@era.ericsson.se> User-Agent: Mutt/1.3.27i 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, Feb 27, 2002 at 10:47:50AM +0100, Magnus Westerlund wrote: > Rob, > > In my opinion they have a useful distinction. The different state represent if > the point of pausing is valid or not. This is part of the state and it helps > clarify behavior regarding pause and play without range. When in ready-na and > receiving a play without range it changes state to playing-na and plays from > the beginning. When in pause-na and receives the same play it will play from > the pause point stored upon entering the pause state. I don't see the distinction. After a successful setup, is the clip not paused at time zero? > > We have had a discussion on this during one of the telecoms. What was raised > then was the following. When a play without range is issued in state ready-na > it starts from the beginning. When the server reaches the end of the media, > what shall it do. My interpretation which is represented in the state machine > is that it returns to ready-na, when doing play without range again it will > start from the beginning. Another interpretation is that it stays at the end > point and any play without range will be accepted but return to ready state > directly as it is at the end. This behavior requires a explicit rewind of the > media with a play with range 0- to start from the beginning. I don't like the idea of the server rewinding the clip without being requested by the client. I would prefer that the end-of-clip functionality match the rest of the protocol, in that the client initiates all of the server's state transitions. When the server reaches the end of the clip, why can't it stay in the playing state until the client sends a pause or teardown? If the server makes the state transition on its own, the client runs the possibility that a pause message very close to the end of the clip could reach the server after the clip has finished and the server is back in the ready/paused state. The expected behaviour doesn't seem to be defined in this case, for either the old or the proposed state machine. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 17:40: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 RAA22858 for ; Wed, 27 Feb 2002 17:40:33 -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 RAA05069; Wed, 27 Feb 2002 17:33:48 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05038 for ; Wed, 27 Feb 2002 17:33:46 -0500 (EST) Received: from clustermail.minx.net.uk ([212.85.249.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22642 for ; Wed, 27 Feb 2002 17:33:40 -0500 (EST) Received: from ppp-4-171.5800-9.telinco.net ([212.1.139.171] helo=connectfree.co.uk) by clustermail.minx.net.uk with esmtp (Exim 3.22 #2) id 16gCmF-0003tV-00 for mmusic@ietf.org; Wed, 27 Feb 2002 22:42:23 +0000 Message-ID: <2734920022327223143800@connectfree.co.uk> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: consulting3@connectfree.co.uk X-MSMail-Priority: Normal From: "Virtumundo, Inc." To: mmusic@ietf.org Date: Wed, 27 Feb 2002 22:31:43 -00 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_84815C5ABAF209EF376268C8" Subject: [MMUSIC] LAPTOP = PARANORMAL 2002 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_84815C5ABAF209EF376268C8 Content-type: text/plain; charset="US-ASCII" ------=_NextPart_84815C5ABAF209EF376268C8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Paranormal 2002
3D"vtrack"
=
3D"CLICK


 
 

You received this email because you signed up at one of Virtumundo's website= s (see the "Properties" listed at http://www=2Evirtumundo=2Ecom) or you signe= d up with a party that has contracted with Virtumundo=2E To unsubscribe from the Virtumundo Rew= ards List, visit http://www=2Evirtumundo=2Ecom/unsub or cli= ck here=2E The products and/or services advertised in this email are the sole responsib= ility of the advertiser, and questions about this offer should be directed to the adv= ertiser=2E
=A9 2002 Virtumundo, Inc=2E All rights reserved=2E

------=_NextPart_84815C5ABAF209EF376268C8-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 18: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 SAA24063 for ; Wed, 27 Feb 2002 18:25: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 SAA07846; Wed, 27 Feb 2002 18:18:39 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07790 for ; Wed, 27 Feb 2002 18:18:37 -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 SAA23867 for ; Wed, 27 Feb 2002 18:18:33 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1RNINP07121; Wed, 27 Feb 2002 18:18:23 -0500 Message-Id: <200202272318.g1RNINP07121@chiron.nge.isi.edu> To: "Fredrik Lindholm (ERA)" cc: "'Peter Barany'" , "'jari.arkko@ericsson.com'" , "Elisabetta Carrara (ERA)" , "'mmusic@ietf.org'" Subject: SDP-new ABNF (was Re: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-02.txt) In-Reply-To: Your message of "Wed, 27 Feb 2002 09:19:37 +0100." <0DAEDF148988D411BB980008C7E65D2E04FE40A3@esealnt416> Date: Wed, 27 Feb 2002 18:18:23 -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: ... >> See Section 6.0 of "MIKEY: >> Multimedia Internet KEYing" where a specific example is given >> (I cut and paste from that I-D below): >> a=keymgmt-data: >> Also, I'm not sure about the usage of "safe" in the SDPbis I-D >> (see "SDP" Session Description >> Protocol". >> >That's a good one. It just disapeared :-) It disappeared because it was inconsistent. RFC 2327 says (section 6): SDP session descriptions are entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attributes names use only the US-ASCII subset of UTF-8, but textual fields and attribute values may use the full ISO 10646 character set. and Text records such as the session name and information are bytes strings which may contain any byte with the exceptions of 0x00 (Nul), 0x0a (ASCII newline) and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers should be tolerant and also accept records terminated with a single newline character. By default these byte strings contain ISO-10646 characters in UTF-8 encoding, but this default may be changed using the `charset' attribute. and in o= restricts the username field to not containing spaces (i.e. the username can be any UTF-8 character except NUL, CR, LF and space). This conflicted with the definition of "safe" in the ABNF, which was much more restrictive. The new ABNF makes username a non-ws-string, which actually matches the text. Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 20:09: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 UAA26753 for ; Wed, 27 Feb 2002 20:09:02 -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 UAA13077; Wed, 27 Feb 2002 20:02:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13046 for ; Wed, 27 Feb 2002 20:02:11 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26614 for ; Wed, 27 Feb 2002 20:02:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA28744; Wed, 27 Feb 2002 18:02:08 -0700 (MST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14159; Wed, 27 Feb 2002 17:02:07 -0800 (PST) Received: from vernors.eng.sun.com (localhost [127.0.0.1]) by vernors.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1S127WF018394; Wed, 27 Feb 2002 17:02:07 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1S1274j018393; Wed, 27 Feb 2002 17:02:07 -0800 (PST) Date: Wed, 27 Feb 2002 17:02:07 -0800 From: Jonathan Sergent To: Tom Marshall Cc: Magnus Westerlund , Rob Lanphier , IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine Message-ID: <20020227170207.C18053@vernors> References: <3C7CAB46.A3239E06@era.ericsson.se> <20020227200947.GA10045@real.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020227200947.GA10045@real.com>; from tmarshall@real.com on Wed, Feb 27, 2002 at 12:09:47PM -0800 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, Feb 27, 2002 at 12:09:47PM -0800, Tom Marshall wrote: > If the server makes the state transition on its own, the client runs the > possibility that a pause message very close to the end of the clip could > reach the server after the clip has finished and the server is back in the > ready/paused state. The expected behaviour doesn't seem to be defined in > this case, for either the old or the proposed state machine. Thank you for agreeing with me (I have pointed this out before but not really gotten anyone to think it is as ugly as I do). This has actually turned up as a bug for us, because we used to refuse PAUSE while paused. The other way around this is to let the server transition in state but to make sure that requests received close to the end of the stream have the same effect as requests received immediately after the end of the stream. Using PLAY with no range header as a "ping" makes this not true. I think the cleanest thing is what you suggest, that the client should need to send a PAUSE if it expects the server to be in the paused state. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Feb 27 20:11: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 UAA26858 for ; Wed, 27 Feb 2002 20:11: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 UAA13233; Wed, 27 Feb 2002 20:04:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA13182 for ; Wed, 27 Feb 2002 20:04:40 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26665 for ; Wed, 27 Feb 2002 20:04:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20636 for ; Wed, 27 Feb 2002 18:04:38 -0700 (MST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14625 for ; Wed, 27 Feb 2002 17:04:38 -0800 (PST) Received: from vernors.eng.sun.com (localhost [127.0.0.1]) by vernors.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g1S14bWF018430 for ; Wed, 27 Feb 2002 17:04:37 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g1S14b25018429 for mmusic@ietf.org; Wed, 27 Feb 2002 17:04:37 -0800 (PST) Date: Wed, 27 Feb 2002 17:04:37 -0800 From: Jonathan Sergent To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine Message-ID: <20020227170437.D18053@vernors> References: <3C7CAB46.A3239E06@era.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C7CAB46.A3239E06@era.ericsson.se>; from magnus.westerlund@era.ericsson.se on Wed, Feb 27, 2002 at 10:47:50AM +0100 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, Feb 27, 2002 at 10:47:50AM +0100, Magnus Westerlund wrote: > We have had a discussion on this during one of the telecoms. What was raised > then was the following. When a play without range is issued in state ready-na > it starts from the beginning. When the server reaches the end of the media, > what shall it do. My interpretation which is represented in the state machine > is that it returns to ready-na, when doing play without range again it will > start from the beginning. Another interpretation is that it stays at the end > point and any play without range will be accepted but return to ready state > directly as it is at the end. This behavior requires a explicit rewind of the > media with a play with range 0- to start from the beginning. A more interesting case to look at is if the initial PLAY request has a closed range in the Range header (i.e. Range: npt=0-15). After playing has stopped due to the closed range, the client sends a PLAY with no range header. Does the stream restart from the beginning, or from npt=15? --jss. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 07:08: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 HAA18391 for ; Thu, 28 Feb 2002 07:08: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 HAA23962; Thu, 28 Feb 2002 07:08: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 HAA23930 for ; Thu, 28 Feb 2002 07:08:08 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18282; Thu, 28 Feb 2002 07:08:05 -0500 (EST) Message-Id: <200202281208.HAA18282@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 28 Feb 2002 07:08:04 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne et al. Filename : draft-ietf-mmusic-rfc2326bis-00.txt Pages : 4 Date : 27-Feb-02 This memorandum is a revision of RFC 2326, which is currently a Proposed Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-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: <20020227125323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-rfc2326bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125323.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 Feb 28 07:08: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 HAA18404 for ; Thu, 28 Feb 2002 07:08:37 -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 HAA24009; Thu, 28 Feb 2002 07:08:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA23972 for ; Thu, 28 Feb 2002 07:08:13 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18300; Thu, 28 Feb 2002 07:08:09 -0500 (EST) Message-Id: <200202281208.HAA18300@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mmusic@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 28 Feb 2002 07:08:09 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdpng-trans-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. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : SDPng Transition Author(s) : J. Ott, C. Perkins Filename : draft-ietf-mmusic-sdpng-trans-00.txt Pages : 12 Date : 27-Feb-02 The Session Description Protocol (SDP) is today widely used in the Internet to announce as well as negotiate multimedia sessions and exchange capabilities. Having originally been designed for session announcements only, as opposed to announcements and capabilities negotiation announcements, native SDP lacks numerous features to be applicable in many session scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-trans-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-sdpng-trans-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-sdpng-trans-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: <20020227125335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdpng-trans-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdpng-trans-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020227125335.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 Feb 28 11:54: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 LAA03781 for ; Thu, 28 Feb 2002 11:54:54 -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 LAA12206; Thu, 28 Feb 2002 11:51:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA12173 for ; Thu, 28 Feb 2002 11:51:06 -0500 (EST) Received: from penguin-ext.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 LAA03520 for ; Thu, 28 Feb 2002 11:51:01 -0500 (EST) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1SGp4B10658 for ; Thu, 28 Feb 2002 17:51:05 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA07511; Thu, 28 Feb 2002 17:51:04 +0100 Message-ID: <3C7E5FF8.58A71CDB@era.ericsson.se> Date: Thu, 28 Feb 2002 17:51:04 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 CC: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine References: <3C7CAB46.A3239E06@era.ericsson.se> <20020227170437.D18053@vernors> Content-Type: multipart/mixed; boundary="------------C9A7BA0DAB2AC7DC54CA3924" 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. --------------C9A7BA0DAB2AC7DC54CA3924 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Rob, Tom and Jonathan, I have reconsidered about removing pause state and I can agree that it is unnecessary. I attach an updated version of the state machine without the paused state. Instead I replaced it with setting of the pause point or as I have called it in the state machine resume point (RP). I think that is a better name for it. I do believe we have the following issues regarding pause, play and reaching end of media or range. - When a presentation reaches end of media or range. Shall it automatically return to ready state? - When a presentation reaches end of media. What shall the resume point be set to? - When reaching end of a range, should the resume point be set to 0 or end of range? - Should we add a end of clip/range notification. I will start with the last issue. I do believe such a mechanism is need for more than this reason to signal the state transition. It will also be good for the buffer handling, retransmission, adaptation, and notification to user. So I do agree that we should add one Then I do believe you are suggesting a control model like a old tape player, I have always thought of it in terms of CD player control. All my CD players return to the beginning of the disc when reaching end. But one thing we really do need to consider is backwards compatibility. Will an RFC 2326 implemented client be able to use a server that would requires a pause before each play after the first? I would guess that it would get into trouble. Also how should this work relative to queued play? Even if we remove as suggested I belive it will be difficult to combine this model with that. Therefore I would like to have automatic return to state READY. I think that the resume point should be reset to 0.0 when reaching end of media. Actually I don't care that much about this behavior except that it should be backwards compatible. If it does not return without a explicit play 0- can this break any client? Regarding reaching end of range I have no strong opinion on what to do as long as it is resolved. The state machine says to set it to 0.0 for moment which is harmonized with end of media behavior. By removing play without range while playing and also queued plays we remove the functionality that has potentials for messing up at end of streams. 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 --------------C9A7BA0DAB2AC7DC54CA3924 Content-Type: text/plain; charset=us-ascii; name="state-machine_v0.3_nopause.txt" Content-Disposition: inline; filename="state-machine_v0.3_nopause.txt" Content-Transfer-Encoding: 7bit RTSP state machine ver. 0.3 This state machine does not contain RECORD which needs to be added. 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. Does not include queued play either. 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. I now have removed the paused state. States Explanation ----------------------------------------------------------------------- Init Initial state no session exist Ready-na Non aggregated session in Ready state Playing-na Non aggregated session in Playing state Paused-na Non aggregated session in Paused state Ready-a Aggregated session in Ready state Playing-a Aggregated session in Playing Paused-a Aggregated session in Pause The reason for separating aggregated and non aggregated states are the following: - Play and Pause may only be done on aggregate URL and not media URLs in aggregated control. In non-aggregated the two are the same. - 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. State: Init Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP Ready-na Nr-media = 1, RP=0.0 State: Ready-na Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media = 2 SETUP Present URL Ready-na Change transport param. Teardown *|media URL Init Ok PLAY No range Playing-na Play from RP PLAY Range Playing-na according to range Timeout Init State: Playing-na Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE No range Ready-na Set RP to present point PAUSE Range > now Playing-na Set RP to given point Pause-point reached Ready-na End of media Ready-na Set RP = 0.0 End of range Ready-na Set RP = 0.0? Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL, Allowed? Playing-na Change transport param. TEARDOWN Allowed? Init State: Ready-a Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media +=1 SETUP Present mediaURL Ready-a Change transport param. TEARDOWN * | Pres URL Init No session hdr. TEARDOWN Nr-media >2 Ready-a Nr-media -=1, sess hdr TEARDOWN Nr-media == 2 Ready-na Nr-media = 1, sess hdr Timeout Init PLAY No range,AggURL Playing-a From RP PLAY Range, Agg URL Playing-a according to range State: Playing-a Action Prerequisite New State Response ----------------------------------------------------------------------- PAUSE No range Ready-a Set RP to present pos. PAUSE Range > now Playing-a Set RP to given point Pause-point reached Ready-a End of range Ready-a Set RP = 0.0? End of media >=1 Media plays Playing-a End of media All media ended Ready-a Set RP to 0.0 Timeout Init SETUP New URL,Allowed? Playing-a Nr-media +=1 SETUP Present URL,Allowed? Playing-a Change transport param TEARDOWN *|pres URL Init No session hdr allowed? TEARDOWN Allowed? Nr-m>2 Playing-a Nr-media -=1, sess hdr TEARDOWN Allowed? Nr-m=2 Playing-na Nr-media = 1, sess hdr --------------C9A7BA0DAB2AC7DC54CA3924-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 12:07: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 MAA04824 for ; Thu, 28 Feb 2002 12:07: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 MAA14556; Thu, 28 Feb 2002 12:03:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA14492 for ; Thu, 28 Feb 2002 12:03:36 -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 MAA04546 for ; Thu, 28 Feb 2002 12:03:31 -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 g1SH3YZc024583 for ; Thu, 28 Feb 2002 18:03:34 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA08151; Thu, 28 Feb 2002 18:03:34 +0100 Message-ID: <3C7E62E6.656013C@era.ericsson.se> Date: Thu, 28 Feb 2002 18:03:34 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine References: <3C7CAB46.A3239E06@era.ericsson.se> <20020227200947.GA10045@real.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-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 have directly answered your questions despite the fact that they are present in my other email today. > > > > We have had a discussion on this during one of the telecoms. What was raised > > then was the following. When a play without range is issued in state ready-na > > it starts from the beginning. When the server reaches the end of the media, > > what shall it do. My interpretation which is represented in the state machine > > is that it returns to ready-na, when doing play without range again it will > > start from the beginning. Another interpretation is that it stays at the end > > point and any play without range will be accepted but return to ready state > > directly as it is at the end. This behavior requires a explicit rewind of the > > media with a play with range 0- to start from the beginning. > > I don't like the idea of the server rewinding the clip without being > requested by the client. > > I would prefer that the end-of-clip functionality match the rest of the > protocol, in that the client initiates all of the server's state > transitions. When the server reaches the end of the clip, why can't it stay > in the playing state until the client sends a pause or teardown? The biggest problem I have with this is backwards compatibility. The proposed behavior requires that you pipeline all play request with a pause the plat to change to ready state. And I don't believe all clients out there has this behavior. > > If the server makes the state transition on its own, the client runs the > possibility that a pause message very close to the end of the clip could > reach the server after the clip has finished and the server is back in the > ready/paused state. The expected behaviour doesn't seem to be defined in > this case, for either the old or the proposed state machine. In the new state machine there is no need. Doing play without range will be decapricated due to the fact that it could cause restarting of stream. If we also remove queued plays the client will receive a error message "not allowed in this state" if the is in playing state. 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 Thu Feb 28 13:52: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 NAA12285 for ; Thu, 28 Feb 2002 13:52:12 -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 NAA21418; Thu, 28 Feb 2002 13:51:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA21387 for ; Thu, 28 Feb 2002 13:51:42 -0500 (EST) Received: from ns2.packetvideo.com (ns2.packetvideo.com [63.214.191.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12236 for ; Thu, 28 Feb 2002 13:51:33 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id g1SIp0t41090 for ; Thu, 28 Feb 2002 10:51:00 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 10:48:44 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A6F18@misty.packetvideo.com> From: Thomas Zeng To: mmusic@ietf.org Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-00.txt Date: Thu, 28 Feb 2002 10:48:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.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 Dear RTSP Authors: In this rfc2326bis draft, it appears TEARDOWN from S->C is not allowed (no change from RFC2326). Is it a mistake or by intention? Thanks, thomas -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, February 28, 2002 4:08 AM Cc: mmusic@ietf.org Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-rfc2326bis-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF. Title : Real Time Streaming Protocol (RTSP) Author(s) : H. Schulzrinne et al. Filename : draft-ietf-mmusic-rfc2326bis-00.txt Pages : 4 Date : 27-Feb-02 This memorandum is a revision of RFC 2326, which is currently a Proposed Standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-rfc2326bis-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mmusic-rfc2326bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mmusic-rfc2326bis-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. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 14:48: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 OAA15668 for ; Thu, 28 Feb 2002 14:48:11 -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 OAA25014; Thu, 28 Feb 2002 14:47: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 OAA24981 for ; Thu, 28 Feb 2002 14:47:47 -0500 (EST) Received: from mail.atelo.com (ns1.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15659 for ; Thu, 28 Feb 2002 14:47:43 -0500 (EST) DATE: 28 Feb 2002 19:47:45 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 28 Feb 2002 19:47:45 Message-ID: X-Mailer: mail.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA24982 Subject: [MMUSIC] Unicast address for media in RTSP 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 Hi Folks, What is the reason why media in unicast session is transmitted to the source of RTSP request? Why can't RTSP client specify different address for unicast session in SDP? Ability to send media to a different destination will be extremely useful to implement applications such as music on hold in SIP call from RTSP source. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 14:57: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 OAA16234 for ; Thu, 28 Feb 2002 14:57:47 -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 OAA25517; Thu, 28 Feb 2002 14:57: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 OAA25488 for ; Thu, 28 Feb 2002 14:57:28 -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 OAA16230 for ; Thu, 28 Feb 2002 14:57:23 -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 g1SJurtC000517; Thu, 28 Feb 2002 11:56:53 -0800 Received: from ROBLA350 ([172.23.100.116]) by real.com (8.12.2/8.12.2) with ESMTP id g1SJusMa028057; Thu, 28 Feb 2002 11:56:54 -0800 Date: Thu, 28 Feb 2002 11:56:51 -0800 (Pacific Standard Time) From: Rob Lanphier To: Roman Shpount cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Unicast address for media in RTSP In-Reply-To: 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 On 28 Feb 2002, Roman Shpount wrote: > What is the reason why media in unicast session is transmitted to the > source of RTSP request? Why can't RTSP client specify different address > for unicast session in SDP? Ability to send media to a different > destination will be extremely useful to implement applications such as > music on hold in SIP call from RTSP source. I'm not sure what you mean here. The client can send a Transport: line that contains a destination parameter, and the server can accept that line. As the spec says, this should be used with caution, and many implementations may forbid anonymous use of this, because of the denial-of-service possibilities associated with this feature. Rob _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 15:48: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 PAA18969 for ; Thu, 28 Feb 2002 15:48:38 -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 PAA29286; Thu, 28 Feb 2002 15:48: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 PAA29251 for ; Thu, 28 Feb 2002 15:48:18 -0500 (EST) Received: from mail.atelo.com (mail.atelo.com [65.107.127.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18949 for ; Thu, 28 Feb 2002 15:48:13 -0500 (EST) DATE: 28 Feb 2002 20:48:15 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 28 Feb 2002 20:48:16 Message-ID: X-Mailer: mail.atelo.com POP3 Server v.1c MIME-Version: 1.0 X-Priority: Normal X-MSMail-Priority: 3 From: Roman Shpount To: Cc: Content-type: TEXT/PLAIN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA29252 Subject: [MMUSIC] Re: Unicast address for media in RTSP 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 On 28 Feb 2002, Roman Shpount wrote: > What is the reason why media in unicast session is transmitted to the > source of RTSP request? Why can't RTSP client specify different address > for unicast session in SDP? Ability to send media to a different > destination will be extremely useful to implement applications such as > music on hold in SIP call from RTSP source. Rob Lanphier wrote: > I'm not sure what you mean here. The client can send a Transport: line > that contains a destination parameter, and the server can accept that > line. As the spec says, this should be used with caution, and many > implementations may forbid anonymous use of this, because of the > denial-of-service possibilities associated with this feature. The latest draft bis as well as the original RFC specify in section 1.6: Unicast: The media is transmitted to the source of the RTSP request, with the port number chosen by the client. Alternatively, the media is transmitted on the same reliable stream as RTSP. This clearly states that the media is always send to the source of the RTSP request and not to the destination specified in the request. This actually contradicts to the section 12.40 of the bis. ___________________________________ Roman Shpount, VP of Technology aTelo, Inc. 2107 Wilson Blvd., Suite 301 Arlington, VA 22201 PCN: 703-621-4040 for voice / fax www.atelo.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 17:52:34 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 RAA24454 for ; Thu, 28 Feb 2002 17:52:34 -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 RAA07398; Thu, 28 Feb 2002 17:52:14 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA07368 for ; Thu, 28 Feb 2002 17:52:13 -0500 (EST) Received: from ns2.packetvideo.com (ns2.packetvideo.com [63.214.191.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24404 for ; Thu, 28 Feb 2002 17:52:08 -0500 (EST) Received: from misty.packetvideo.com (pv-fw [63.214.191.66]) by ns2.packetvideo.com (8.11.4/8.11.4) with ESMTP id g1SMpet46980; Thu, 28 Feb 2002 14:51:40 -0800 (PST) Received: by misty.packetvideo.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 14:49:24 -0800 Message-ID: <72263E8E8622D611975C0002B32C19D84A6F1D@misty.packetvideo.com> From: Thomas Zeng To: "'Magnus Westerlund'" Cc: IETF MMUSIC WG , Greg Sherwood , Sue Wilson Subject: RE: [MMUSIC] RTSP state machine Date: Thu, 28 Feb 2002 14:49:22 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Filter-Version: 1.6a (ns2.packetvideo.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 Dear Magnus: A couple of comments on your state machine document: 1. For ready state, you have: State: Ready-na Action Prerequisite New State Response ----------------------------------------------------------------------- SETUP New URL Ready-a Nr-media = 2 SETUP Present URL Ready-na Change transport param. Teardown *|media URL Init Ok I think in last telecon we agreed that TEARDOWN with "Presentation URL" releases the session ID and takes the session to INIT state. BTW, I don't believe TEARDOWN on "media URL", even if Nr-media = 0 as a result, should release the session ID. Suggest the addition of "Ready-No-Track" state? 2. On TIMEOUT handling: If the server times out on a client, I would suggest that server send a TEARDOWN to client (if TEARDOWN is allowed in the S->C direction, which is a separate thread of discussion). 3. On end of stream/range notification: I agree with your proposal. Please also see the feature request I submited to sourceforge below. Incidentally, Rob L. suggested that TEARDOWN in the S->C direction be used to serve as notification before END_OF_STREAM is added to RTSP. Best regards, thomas ---------------cut here --------------- Feature Requests item #522607, was opened at 2002-02-25 11:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377747&aid=522607&group_id= 23194 Category: None Group: None Status: Open Priority: 5 Submitted By: Thomas M Zeng (zengtm) Assigned to: Nobody/Anonymous (nobody) Summary: Need END_OF_STREAM request Initial Comment: Currently there is no way for Server to inform Client the completion of a presentation (VOD or Live) without issuing a TEARDOWN and thus release reources. What if the player wants to use the same resources (pertinent to its sessionID) to watch another clip? It would be wasteful to teardown and then acquire another sessionID immediately. Would like to see a END_OF_STREAM method added on the S->C direction. E.g.: END_OF_STREAM or RTSP/1.0 SESSION: REASON: -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@era.ericsson.se] Sent: Thursday, February 28, 2002 8:51 AM Cc: IETF MMUSIC WG Subject: Re: [MMUSIC] RTSP state machine Hi Rob, Tom and Jonathan, I have reconsidered about removing pause state and I can agree that it is unnecessary. I attach an updated version of the state machine without the paused state. Instead I replaced it with setting of the pause point or as I have called it in the state machine resume point (RP). I think that is a better name for it. I do believe we have the following issues regarding pause, play and reaching end of media or range. - When a presentation reaches end of media or range. Shall it automatically return to ready state? - When a presentation reaches end of media. What shall the resume point be set to? - When reaching end of a range, should the resume point be set to 0 or end of range? - Should we add a end of clip/range notification. I will start with the last issue. I do believe such a mechanism is need for more than this reason to signal the state transition. It will also be good for the buffer handling, retransmission, adaptation, and notification to user. So I do agree that we should add one Then I do believe you are suggesting a control model like a old tape player, I have always thought of it in terms of CD player control. All my CD players return to the beginning of the disc when reaching end. But one thing we really do need to consider is backwards compatibility. Will an RFC 2326 implemented client be able to use a server that would requires a pause before each play after the first? I would guess that it would get into trouble. Also how should this work relative to queued play? Even if we remove as suggested I belive it will be difficult to combine this model with that. Therefore I would like to have automatic return to state READY. I think that the resume point should be reset to 0.0 when reaching end of media. Actually I don't care that much about this behavior except that it should be backwards compatible. If it does not return without a explicit play 0- can this break any client? Regarding reaching end of range I have no strong opinion on what to do as long as it is resolved. The state machine says to set it to 0.0 for moment which is harmonized with end of media behavior. By removing play without range while playing and also queued plays we remove the functionality that has potentials for messing up at end of streams. 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Feb 28 22:02: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 WAA01156 for ; Thu, 28 Feb 2002 22:02:52 -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 WAA19166; Thu, 28 Feb 2002 22:02:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA19135 for ; Thu, 28 Feb 2002 22:02:29 -0500 (EST) Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01151 for ; Thu, 28 Feb 2002 22:02:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03772 for ; Thu, 28 Feb 2002 20:02:27 -0700 (MST) Received: from moe (silveroak.Eng.Sun.COM [129.146.81.98]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24730 for ; Thu, 28 Feb 2002 19:02:26 -0800 (PST) Date: Wed, 27 Feb 2002 19:38:40 -0800 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed From: Jonathan Sergent To: mmusic@ietf.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Fwd: I-D ACTION:draft-sergent-rtsp-mute-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 Content-Transfer-Encoding: 7bit This is an internet-draft for MUTE and UNMUTE proposal that we discussed on the RTSP teleconference. Note the open issues list at the end. (Please also note that I got the snail mail and telephone contact information wrong due to an editing error. Oops.) Feedback/comments/questions from all are welcome. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: Wed Feb 27, 2002 04:24:16 AM US/Pacific > To: IETF-Announce: ; > Subject: I-D ACTION:draft-sergent-rtsp-mute-00.txt > Reply-To: Internet-Drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MUTE and UNMUTE extension to RTSP > Author(s) : A. Narasimhan, J. Sergent > Filename : draft-sergent-rtsp-mute-00.txt > Pages : 8 > Date : 26-Feb-02 > > RFC 2326 [1] overloads the functionality of the PLAY and PAUSE > methods to provide rudimentary support for 'muting' individual > streams in an (Real Time Streaming Protocol) presentation. The > current specification has several inconsistencies. In addition, we > believe that this functionality should be optional. This document > specifies an extension to RTSP consisting of new MUTE and UNMUTE > methods, providing equivalent functionality in a consistent, optional > manner. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sergent-rtsp-mute-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-sergent-rtsp-mute-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-sergent-rtsp-mute-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. > Content-Type: text/plain > Content-ID: <20020226130631.I-D@ietf.org> _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic