From mmusic-admin@ietf.org Thu Jan 3 01:48: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 BAA18560 for ; Thu, 3 Jan 2002 01:48: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 BAA16585; Thu, 3 Jan 2002 01:48: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 BAA16549 for ; Thu, 3 Jan 2002 01:48:35 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18556 for ; Thu, 3 Jan 2002 01:48:34 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.79]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g036kCVZ006049; Thu, 3 Jan 2002 01:46:12 -0500 (EST) Message-ID: <3C33FE18.1070006@dynamicsoft.com> Date: Thu, 03 Jan 2002 01:45:44 -0500 From: Jonathan Rosenberg 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: Colin Perkins CC: Paul Kyzivat , Jerry Wong , "'sip-implementors@cs.columbia.edu'" , Aliza Nagauker , mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip-implementors] SIP and SDP References: <200201011728.g01HSTl01668@purple.nge.isi.edu> 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 Colin, I could have sworn we once had a conversation about why using domain names in SDP was a bad idea, and that this was the motivation for its removal from sdp-new, although I don't remember the reason. Am I mis-remembering (a definite possibility), or is there some issue with domain names? -Jonathan R. Colin Perkins wrote: > --> Paul Kyzivat writes: > >>It was FQDN in RFC2327. Then, it became just IP4-address or IP6-address >>in draft-ietf-mmusic-sdp-new-02 and -03, but went back to FQDN in >>draft-ietf-mmusic-sdp-new-04. >> >>I don't know which is preferred for use with SIP. But it would be nice >>if somebody would make up their mind. >> > > draft-ietf-mmusic-sdp-new is intended to match RFC2327. If it doesn't, > let > me know and I'll fix it. > > Colin > > -- 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 Jan 3 06:26: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 GAA29163 for ; Thu, 3 Jan 2002 06:26: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 GAA24981; Thu, 3 Jan 2002 06:20: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 GAA24947 for ; Thu, 3 Jan 2002 06:20:38 -0500 (EST) Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29132 for ; Thu, 3 Jan 2002 06:20:35 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g03BK5B24550 for ; Thu, 3 Jan 2002 06:20:06 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Thu, 3 Jan 2002 11:20:05 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB001AC3523@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Flemming Andreasen , "'Paul Kyzivat'" Cc: Jonathan Rosenberg , mmusic@ietf.org, confctrl@isi.edu Subject: RE: [MMUSIC] Re: resolving open issues in offer/answer Date: Thu, 3 Jan 2002 11:19:56 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 null argument for not having the requirement. As specified, it is a perfectly accepted normative requirement. As regards conformance, it cannot be tested with a single point of control and observation. Conformance could however be determined with an additional point of control and observation between the application process and the SDP process. Conformance testers don't like this, because it is rarely provided as an accessible interface in implementations, but testing standards do acknowledge the existence of such a testing model. Lets concentrate on whether it is a reasonable requirement in the first place. Keith Keith Drage Lucent Technologies Tel: +44 1793 776249 Email: drage@lucent.com > ---------- > From: Paul Kyzivat[SMTP:pkyzivat@cisco.com] > Sent: 21 December 2001 13:55 > To: Flemming Andreasen > Cc: Jonathan Rosenberg; mmusic@ietf.org; confctrl@isi.edu > Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer > > Sorry, but I still don't get it. > > Let me put it another way. This is adding normative language requiring > the sender of SDP to be prepared to send. How would that be verified? Is > there any possible way to distinguish between being unprepared to send > (nonconforming) and simply having no desire to send (conforming)? > > Paul > > Flemming Andreasen wrote: > > > > Paul Kyzivat wrote: > > > > > Comments below - Paul > > > > > > Jonathan Rosenberg wrote: > > > > > > > > Folks, > > > > > > > > I want to try and move swiftly towards closure of the open issues in > > > > offer/answer. I presented slides at IETF 52 on these issues, which > you > > > > can pick up from: > > > > > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you > send > > > > the SDP. Consensus to update text to indicate that you need to be > > > > prepared to both send and receive. > > > > > > I don't understand the point in requiring someone to be prepared to > > > send. > > > > > > > There were two issues here. First one was that we always want codecs > listed on > > a bi-directional stream to indicate a send and receive capability. > Second one > > was, that even if you have only sent an initial offer, and not yet > gotten a > > response, it is possible to send media when using connection-oriented > media > > streams if the connection is established before you get the answer. In > that > > case, you need to be prepared to both send and receive at the time of > the > > offer. > > _______________________________________________ > 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 Jan 3 09:24: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 JAA01879 for ; Thu, 3 Jan 2002 09:24: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 JAA00091; Thu, 3 Jan 2002 09:23: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 JAA00058 for ; Thu, 3 Jan 2002 09:23:24 -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 JAA01865 for ; Thu, 3 Jan 2002 09:23:20 -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 g03EMtL22862; Thu, 3 Jan 2002 09:22:55 -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 AAH60302 (AUTH pkyzivat); Thu, 3 Jan 2002 09:24:08 -0500 (EST) Message-ID: <3C346832.AD401318@cisco.com> Date: Thu, 03 Jan 2002 09:18:26 -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: "Drage, Keith (Keith)" CC: Flemming Andreasen , Jonathan Rosenberg , mmusic@ietf.org, confctrl@isi.edu Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer References: <475FF955A05DD411980D00508B6D5FB001AC3523@en0033exch001u.uk.lucent.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 OK. I will shut up. The requirement seems silly to me, but if others want to believe it is meaningful then it does little harm to leave it. Paul "Drage, Keith (Keith)" wrote: > > This is a null argument for not having the requirement. > > As specified, it is a perfectly accepted normative requirement. As regards > conformance, it cannot be tested with a single point of control and > observation. Conformance could however be determined with an additional > point of control and observation between the application process and the SDP > process. Conformance testers don't like this, because it is rarely provided > as an accessible interface in implementations, but testing standards do > acknowledge the existence of such a testing model. > > Lets concentrate on whether it is a reasonable requirement in the first > place. > > Keith > > Keith Drage > Lucent Technologies > Tel: +44 1793 776249 > Email: drage@lucent.com > > > ---------- > > From: Paul Kyzivat[SMTP:pkyzivat@cisco.com] > > Sent: 21 December 2001 13:55 > > To: Flemming Andreasen > > Cc: Jonathan Rosenberg; mmusic@ietf.org; confctrl@isi.edu > > Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer > > > > Sorry, but I still don't get it. > > > > Let me put it another way. This is adding normative language requiring > > the sender of SDP to be prepared to send. How would that be verified? Is > > there any possible way to distinguish between being unprepared to send > > (nonconforming) and simply having no desire to send (conforming)? > > > > Paul > > > > Flemming Andreasen wrote: > > > > > > Paul Kyzivat wrote: > > > > > > > Comments below - Paul > > > > > > > > Jonathan Rosenberg wrote: > > > > > > > > > > Folks, > > > > > > > > > > I want to try and move swiftly towards closure of the open issues in > > > > > offer/answer. I presented slides at IETF 52 on these issues, which > > you > > > > > can pick up from: > > > > > > > > > ISSUE 2: Be prepared to send&recv on bidirectional stream when you > > send > > > > > the SDP. Consensus to update text to indicate that you need to be > > > > > prepared to both send and receive. > > > > > > > > I don't understand the point in requiring someone to be prepared to > > > > send. > > > > > > > > > > There were two issues here. First one was that we always want codecs > > listed on > > > a bi-directional stream to indicate a send and receive capability. > > Second one > > > was, that even if you have only sent an initial offer, and not yet > > gotten a > > > response, it is possible to send media when using connection-oriented > > media > > > streams if the connection is established before you get the answer. In > > that > > > case, you need to be prepared to both send and receive at the time of > > the > > > offer. > > > > _______________________________________________ > > 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 Jan 3 11:53: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 LAA05920 for ; Thu, 3 Jan 2002 11:53: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 LAA08829; Thu, 3 Jan 2002 11:53: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 LAA08794 for ; Thu, 3 Jan 2002 11:53:16 -0500 (EST) Received: from cerbrus.convedia.com (cerbrus.convedia.com [216.129.93.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05902 for ; Thu, 3 Jan 2002 11:53:12 -0500 (EST) Received: from ladon.convedia.com (ladon [192.168.208.15]) by cerbrus.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09746; Thu, 3 Jan 2002 08:51:34 -0800 (PST) Received: from convedia.com (dhcp06 [192.168.208.195]) by ladon.convedia.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25966; Thu, 3 Jan 2002 08:53:23 -0800 (PST) Message-ID: <3C348BF7.9010105@convedia.com> Date: Thu, 03 Jan 2002 08:51:03 -0800 From: Tim Melanchuk User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010913 X-Accept-Language: en-us MIME-Version: 1.0 To: Jonathan Rosenberg CC: Colin Perkins , Paul Kyzivat , Jerry Wong , "'sip-implementors@cs.columbia.edu'" , Aliza Nagauker , mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip-implementors] SIP and SDP References: <200201011728.g01HSTl01668@purple.nge.isi.edu> <3C33FE18.1070006@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit One issue which I recall being briefly discussed was SIP recovery strategies when the resolution of an FQDN connection address fails. This may be a more common occurance in 3pcc where the signalling and media paths are separate. There is no standard way for one UA to tell another that it's connection address could not be resolved but that otherwise the media characteristics are ok. Although an additional warning code could indicate this if the connection address in an offer could not be resolved, if that in the answer can't be resolved, I'm not sure what the solution would be. A re-INVITE, although it could remove the media stream which had the failed connection address, would offer the same media and probably result in an answer containing the FQDN which could not be resolved. timm Jonathan Rosenberg wrote: > Colin, > > I could have sworn we once had a conversation about why using domain > names in SDP was a bad idea, and that this was the motivation for its > removal from sdp-new, although I don't remember the reason. Am I > mis-remembering (a definite possibility), or is there some issue with > domain names? > > -Jonathan R. > > Colin Perkins wrote: > >> --> Paul Kyzivat writes: >> >>> It was FQDN in RFC2327. Then, it became just IP4-address or IP6-address >>> in draft-ietf-mmusic-sdp-new-02 and -03, but went back to FQDN in >>> draft-ietf-mmusic-sdp-new-04. >>> I don't know which is preferred for use with SIP. But it would be nice >>> if somebody would make up their mind. >>> >> >> draft-ietf-mmusic-sdp-new is intended to match RFC2327. If it doesn't, >> let >> me know and I'll fix it. >> >> Colin >> >> > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 3 17:50: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 RAA12964 for ; Thu, 3 Jan 2002 17:50: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 RAA23501; Thu, 3 Jan 2002 17:49:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23467 for ; Thu, 3 Jan 2002 17:49:38 -0500 (EST) Received: from schizophrenia.nge.isi.edu (schizophrenia.nge.isi.edu [65.114.169.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12949 for ; Thu, 3 Jan 2002 17:49:34 -0500 (EST) Received: from schizophrenia (csp@localhost) by schizophrenia.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g03MnSb03357; Thu, 3 Jan 2002 17:49:28 -0500 Message-Id: <200201032249.g03MnSb03357@schizophrenia.nge.isi.edu> To: Jonathan Rosenberg cc: Paul Kyzivat , Jerry Wong , "'sip-implementors@cs.columbia.edu'" , Aliza Nagauker , mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip-implementors] SIP and SDP In-Reply-To: Your message of "Thu, 03 Jan 2002 01:45:44 EST." <3C33FE18.1070006@dynamicsoft.com> Date: Thu, 03 Jan 2002 17:49: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 recall the conversation, although that doesn't necessarily mean that it didn't happen :) Colin --> Jonathan Rosenberg writes: >Colin, > >I could have sworn we once had a conversation about why using domain >names in SDP was a bad idea, and that this was the motivation for its >removal from sdp-new, although I don't remember the reason. Am I >mis-remembering (a definite possibility), or is there some issue with >domain names? > >-Jonathan R. > >Colin Perkins wrote: > >> --> Paul Kyzivat writes: >> >>>It was FQDN in RFC2327. Then, it became just IP4-address or IP6-address >>>in draft-ietf-mmusic-sdp-new-02 and -03, but went back to FQDN in >>>draft-ietf-mmusic-sdp-new-04. >>> >>>I don't know which is preferred for use with SIP. But it would be nice >>>if somebody would make up their mind. >>> >> >> draft-ietf-mmusic-sdp-new is intended to match RFC2327. If it doesn't, >> let >> me know and I'll fix it. >> >> Colin >> >> > > >-- >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 Jan 4 03:37: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 DAA29243 for ; Fri, 4 Jan 2002 03:37: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 DAA14479; Fri, 4 Jan 2002 03:37: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 DAA14446 for ; Fri, 4 Jan 2002 03:37:03 -0500 (EST) Received: from bullwinkle.real.com ([207.188.22.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29239 for ; Fri, 4 Jan 2002 03:37:00 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Fri, 04 Jan 2002 00:34:23 -0800 Received: from [192.168.104.21] (12-231-29-208.client.attbi.com [12.231.29.208]) by prognet.com (8.9.2/8.9.0) with ESMTP id AAA07267 for ; Fri, 4 Jan 2002 00:36:44 -0800 (PST) Date: Fri, 4 Jan 2002 00:36:20 -0800 (PST) From: Rob Lanphier X-X-Sender: robla@mmmm.robla.org To: mmusic@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP issue tracking teleconference (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 Hi all, If you haven't RSVPed yet for this telecon (see email below), now is the last call. We plan to have it Wednesday, January 9, at 9:00am PST (12:00pm EST; 17:00 GMT). If you didn't receive a separate email from me (titled "RTSP telecon") and you *did* RSVP, chances are I accidently left you off of the list. Email me again, and I'll make sure you get all of the info to call in. Thanks Rob ---------- Forwarded message ---------- Date: Thu, 13 Dec 2001 21:20:19 -0800 From: Rob Lanphier To: "confctrl@ISI.EDU" Subject: RTSP issue tracking teleconference Hi all, We plan on setting up a teleconference for sometime at the beginning of the year (January 8, 10am I think is the tentative time). We'd like to have a discussion about the following list: http://sourceforge.net/tracker/index.php?group_id=23194&atid=377744&_group=166369 Please let me know if you would like to call in for this. We reserve the right to trim the list if it gets too large ("we" being Henning and I [and Anup once we let him know...if you're reading, Hi Anup!] with oversight from the chairs of this working group). One of the trimming algorithms we may use is whether you've expressed an opinion on this email list regarding at least one of the issues in the list above (favoring those who have), so please start the discussion on this list. No decisions will be final, and we plan to send email to this list with resolutions and enter resolutions in the bug tracker. Thanks Rob _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 4 12:33: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 MAA09176 for ; Fri, 4 Jan 2002 12:33: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 MAA00542; Fri, 4 Jan 2002 12:32: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 MAA00507 for ; Fri, 4 Jan 2002 12:32:37 -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 MAA09169 for ; Fri, 4 Jan 2002 12:32:33 -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 JAA19219; Fri, 4 Jan 2002 09:31:54 -0800 (PST) Message-ID: <3C35E72D.7A9D3FB6@cisco.com> Date: Fri, 04 Jan 2002 12:32:29 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Paul Kyzivat , mmusic@ietf.org, confctrl@ISI.EDU Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer References: <3C2342E1.83EB1CFD@cisco.com> <3C27AC61.5010909@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: > > > > > Paul Kyzivat wrote: > > > > > >>Sorry, but I still don't get it. > >> > >>Let me put it another way. This is adding normative language requiring > >>the sender of SDP to be prepared to send. How would that be verified? > >> > > Is > > > >>there any possible way to distinguish between being unprepared to send > >>(nonconforming) and simply having no desire to send (conforming)? > >> > > > > No, but it ensures, that if the answerer picks any one of those codecs, > > then the > > offerer will actually be able to send, should he so desire. > > I think what you are looking for is a sentence that says: > > When the offerer receives the answerer, it MAY send media on that stream > (assuming it is listed as sendrecv or recvonly in the answer). It SHOULD > use the first media format listed in the answer when it does send. > Not really :-) > > I will add that. I agree with Paul that saying you MUST be prepared to > send when you generate an offer is pointless, since it can't actually > send, and therefore there is no way to actually verify this requirement. I'm obviously doing a poor job of expressing myself clearly, however I believe we have agreed on the underlying issue (that all codecs listed in a sendrecv media stream must be supported for send and receive in both the offer and answer). Given that, I'm happy to leave this for now and just take a look at the next version of the draft. -- Flemming > > > -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 Fri Jan 4 12:38: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 MAA09283 for ; Fri, 4 Jan 2002 12:38: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 MAA00743; Fri, 4 Jan 2002 12:37: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 MAA00709 for ; Fri, 4 Jan 2002 12:37: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 MAA09280 for ; Fri, 4 Jan 2002 12:37:48 -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 JAA21989; Fri, 4 Jan 2002 09:36:57 -0800 (PST) Message-ID: <3C35E85C.94860944@cisco.com> Date: Fri, 04 Jan 2002 12:37:32 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Paul E. Jones" , MMUSIC , mmusic@ietf.org Subject: Re: [MMUSIC] Why must PT be the same in send and receive directio n ? References: <012c01c189e7$a4afcd40$63a86840@cisco.com> <3C29EAC8.6040504@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: > In the interests of cooperation and forward progress, here is a proposal. > > The spec states that the answerer MUST use the same PT in forward and > reverse directions, but that in some interworking cases when the > answerer is a gateway, it is not possible to meet this. Therefore, the > offerer SHOULD be prepared to see different dynamic PT in the answer. > Sounds good. > > I will note that proposals like this (sender MUST NOT do something, but > receiver MUST be prepared to handle it anyway) have led to > interoperability issues in the past. Be conservative in what you send and liberal in what you receive. > Thus, if we take this route, we > must do so cautiously, providing sufficient motivation for people to > understand why this was done. > > I'd like to see some inputs from implementors on the burden of > supporting different PT in forward and reverse directions.... I've checked with some of our implementers, and they don't see a problem at least (anybody supporting H.323 should not have a problem in this area) -- Flemming > > > -Jonathan R. > > Paul E. Jones wrote: > > > Flemming and Jonathan, > > > > I think the reason that the symmetry of PTs has not been an issue up to > > this > > point are two-fold: > > 1) Interworking between H.245 and SDP-based systems has had less focus > > 2) There have previously been few dynamic PTs used within H.245 > > for which people have tried to interwork with SDP-based > > (Of course, they are used, but few people have cared about whether > > those PTs being used worked with SDP-based systems or not. I > > believe > > the first problem encounter that is of concern is the interworking > > of RFC 2833.) > > > > As we look at new codec types and the exchange of other signaling that > > rely > > on dynamic payload types, the H.323/SDP interworking problems in this > > area > > are forcing us to take note of the issues here. > > > > Within H.323, it is possible to exchange PTs in two ways: > > 1) In the Setup message, and endpoint may propose "forward" > > and "reverse" audio/video/data channels and include the > > dynamic payload types > > 2) The PTs might be conveyed through H.245 capabilities exchange > > (which is asymmetrical by nature) > > > > In either case, it is possible to have asymmetric usage of payload > > types. I > > would suspect that in most cases, endpoint vendors who use (1) will > > specify > > the same PT for the "forward" and the "reverse" audio channel, though > > that > > is not required.For channels opened with knowledge learned through > > (2), > > there is certainly no guarantee of symmetric payload types. > > Additionally, > > there has not been a sense that such a restrictive requirement is > > necessary. > > > > Media clipping is not an issue in (1) any more so than when using > > SDP-based > > protocols. However, the use of (2) alone certainly might increase the > > chances of clipping media, as the PTs may not be known at the calling > > endpoint before media is received. Hence, method (1) is strongly > > encouraged, with method (2) used to provide information about > > capabilities > > that may be utilized during or after call setup that less time > > sensitive, > > such as T.120 multipoint data conferencing. (2) is also used in order > > to > > establish A/V communication wherein the proposals from (1) are not > > acceptable to the called party. > > > > In any case, interoperability between the two systems when using dynamic > > payload types is a real issue that we need to tackle. > > > > Paul > > > > ----- Original Message ----- > > From: "Flemming Andreasen" > > To: "Jonathan Rosenberg" > > Cc: "MMUSIC" ; ; "Paul E Jones" > > > > Sent: Thursday, December 20, 2001 1:36 PM > > Subject: Re: [MMUSIC] Why must PT be the same in send and receive > > direction > > ? > > > > > > > >> > >>Jonathan Rosenberg wrote: > >> > >> > >>>Flemming Andreasen wrote: > >>> > >>> > >>>>The offer/answer model is quite explicit in stating that the > >>>> > > payload > > > >>>>type for a given codec MUST be the same in the send and receive > >>>>direction and hence the payload type mapping for codec X in MUST > >>>> > > be > > the > > > >>>>same in the offer and answer. However, this can cause a great deal > >>>> > > of > > > >>>>grief when interworking with H.323 based systems, since they can't > >>>>necessarily guarantee this property. > >>>> > >>>>Now I can't think of a lot of reasons for the above offer/answer > >>>>restriction, except that it guarantees a proper interpretation of > >>>> > > a > > > >>>>given payload type prior to receiving the actual answer to the > >>>> > > offer. > > > >>>Well, thats a good one. You are guaranteed to have media clipping > >>>without this feature. > >>> > >>> > >>Not quite: you are not guaranteed to not have media clipping without > >>this > >>feature. > >> > >> > >>>It also makes it easy for the offerer to determine, from the answer, > >>> > > the > > > >>>matching of codecs in the offer to the answer. Its a simple numeric > >>>comparison. > >>> > >>True > >> > >> > >>>Without the same PT numbers, you need to do a > >>>canonicalization based on the actual codec and parameters. Even > >>> > > minor > > > >>>inconsistencies in the construction of the rtpmaps in the answer can > >>>cause confusion about which codec is which. > >>> > >>Not sure I see that. The only rule we have right now is that the > >> > > payload > > > >>type > >>mapping must be the same in both directions, hence the only difference > >>is > >>whether you follow a dynamic payload type mapping to its canonical > >> > > name > > > >>or > >>not. > >> > >> > >> > >>>Its also consistent with multicast operation. > >>> > >>>Overall, I think its just simpler. > >>> > >>I agree with that, but I don't see a huge difference. > >> > >> > >> > >>>>Unless there is another good reason for the restriction, I would > >>>> > > like > > to > > > >>>>propose, that we allow it to be relaxed, i.e. turn it into a > >>>> > > SHOULD > > and > > > >>>>put in a proper note explaining what might happen if you don't > >>>> > > follow > > > >>>>it. > >>>> > >>>Well, this turns into an interop nightmare for sip. We will have a > >>>complete interop failure if a new UA generates an answer with > >>> > > different > > > >>>payload types. > >>> > >>>This text has also been in there for a very long time. > >>> > >>I know and that's a big concern to me too (if we were to make any > >>changes). > >> > >> > >> > >>>How come no one > >>>complained about this H.323 issue before? Its the first I've heard > >>> > > of > > it. > > > >>Don't know, but it's apparently been around for a while. My H.323 > >>expertise is > >>admittedly a little rusty (cc'ing more knowledgeable people here), but > >> > > I > > > >>believe the problem is that the H.245 OpenLogicaChannel request can be > >>used to > >>open a uni-directional or bi-directional stream, however in either > >> > > case, > > > >>it is > >>possible that the sender and receiver end up specifying different > >>payload type > >>mappings for a given codec. This is particular troublesome in the case > >>where > >>the two sides open a uni-directional stream to the other side in > >>parallel. > >> > >>Given the long-standing existing SDP/offer/answer baggage we have > >> > > here, > > > >>I > >>believe you need to go for the lowest common denominator when mapping > >>between > >>SIP/SDP and H.323, and hence H.323 should have procedures in place to > >>resolve > >>asymmetric payload type mappings in cases where you need symmetry, but > >> > > I > > > >>wanted to raise the issue here to see what people think. > >> > >>Thanks > >> > >> Flemming > >> > >> > >>>-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 > >> > >> > > > > -- > 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 Fri Jan 4 12:59: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 MAA09704 for ; Fri, 4 Jan 2002 12:59: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 MAA01223; Fri, 4 Jan 2002 12:58: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 MAA01190 for ; Fri, 4 Jan 2002 12:58:57 -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 MAA09698 for ; Fri, 4 Jan 2002 12:58:53 -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 JAA04533; Fri, 4 Jan 2002 09:58:16 -0800 (PST) Message-ID: <3C35ED5B.A40B3E98@cisco.com> Date: Fri, 04 Jan 2002 12:58:52 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: mmusic@ietf.org, confctrl@ISI.EDU Subject: Re: [MMUSIC] resolving open issues in offer/answer References: <3C22C8A7.3EAB9B9@cisco.com> <3C2A10EB.9030900@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: > > > > > Jonathan Rosenberg wrote: > > > >>1. change the ssrc when you send with the new codec set. The receiver > >>can drop uneeded codecs when it sees the new ssrc. This only works for > >>unicast. > >> > > > > Actually, I don't even think it does. If you have multiple senders > > sending > > media to you, how do you know which SSRC corresponds to which sender ? > > Also, > > it is possible than an SSRC change might happen for other reasons > > (admittedly, we are getting down to a rather small window for this > > race). > > Realistically, for this to work, you would need to include the actual > SSRC rather than simply waiting for a change in the ssrc. That would > resolve the issues you raise above, but requires an additional SDP > parameter. > > Its worth noting that there is another advantage of the ssrc parameter, > which is that it will allow us to correlate a media stream from a > particular source to a specific dialog, in the event the demux is not > done at the port level. This will happen in the case where we have a > forked INVITE that results in two 200 OK. Each answerer will end up > sending to the same offererd port. Having something in the answer, like > the ssrc, which will allow for disambiguation, would help. That's a good point - it would be very helpful indeed. > > > Of course, there is the associated ugliness with collisions resulting in > a change in ssrc.... > I think it is imperative, that such an "SSRC" attribute only be advisory in nature, i.e a hint. If you receive packets with a known SSRC, you know what to do, but if you receive packets with an unknown SSRC, everything must still work. Also, since not all implementations would support such an extension, we still need rules for what to do in the absence of this attribute and/or other SSRCs. > > However, this proposal is worth further consideration. It gives us an > explicit, reliable, rapid way to associate media streams with signaling, > and I think thats fairly valuable. I agree. > I will admit that changing SSRC might > introduce some confusion into systems; I welcome inputs on specific > problems it might cause. > Again, I think it is important to have some flexibility surrounding the use of such an SSRC attribute, and see it as an optimization hint as opposed to enforcing strict rules. As far as problems go, SRTP security contexts (which key off the SSRC) would seem to be potentially troublesome. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 4 13:22: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 NAA10023 for ; Fri, 4 Jan 2002 13:22: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 NAA02022; Fri, 4 Jan 2002 13:21:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA01982 for ; Fri, 4 Jan 2002 13:21:53 -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 NAA10014; Fri, 4 Jan 2002 13:21:51 -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 KAA18657; Fri, 4 Jan 2002 10:21:04 -0800 (PST) Message-ID: <3C35F2B3.FD96229B@cisco.com> Date: Fri, 04 Jan 2002 13:21:39 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: "Drage, Keith (Keith)" , sip@ietf.org, mmusic@ietf.org, confctrl@isi.edu Subject: Re: [MMUSIC] Re: [Sip] Open Issue #150: too many ways of saying " don't send me media" References: <3C22B0AC.2E1DDE79@cisco.com> <3C2A4972.7050101@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: > > > > > >>The semantics are: > >> > >>c=0.0.0.0: will cease reception of RTP and RTCP, no longer the > >>recommended way to do hold, has issues with SRTP keying, ipv6, > >>connection oriented media, etc. Generally bad. > >> > >>a=inactive/sendonly - stops only RTP > >> > >>port 0: turns of media streams - safe to unload codecs, etc. > >> > >>bw=0: will turn off reception of RTP and RTCP > >> > > > > Do we really need the "bw" one ? > > No, its not really NEEDED. The point Henning had made at IETF is that > the treatment for any bandwidth number is well defined; in that case, > disallowing zero is a special case. I see no reason to disallow it as a > special case when it has defined meaning for all values. > I'm not sure I agree with this. Let's say I specify a bw of 1 kilobit, and the only codec supported currently is G.711. What do I do ? There are several parameters that can have more or less sensible values associated with them and having a bandwidth specify less than the current codecs is not sensible IMO. All you are doing is defining yet another implicit way of signaling something for which there is already explicit signaling support in place. I'd rather reduce the number of well-defined options for expressing something than increasing it. Not a big deal either way to me, but more of a general design principle - I'll leave it up to you. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 4 15:07: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 PAA12884 for ; Fri, 4 Jan 2002 15:07: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 PAA05407; Fri, 4 Jan 2002 15:07:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA05372 for ; Fri, 4 Jan 2002 15:07:38 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12878 for ; Fri, 4 Jan 2002 15:07:37 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04K7aVZ007156; Fri, 4 Jan 2002 15:07:37 -0500 (EST) Message-ID: <3C360B6B.9010306@dynamicsoft.com> Date: Fri, 04 Jan 2002 15:07:07 -0500 From: Jonathan Rosenberg 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: Paul Kyzivat CC: mmusic@ietf.org, confctrl@ISI.EDU References: <3C223470.18E804AE@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: resolving open issues 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 Paul Kyzivat wrote: > Comments below - Paul > >>ISSUE 3: Multiple streams of the same type. See the slides for the >>issue. My proposal was accepted, with the caveat that we would add >>wording to clarify that the default operation is NOT to copy media >>from your own local sinks to sources, unless you happen to be a conference >>server. >> > > I don't have any substantial objection to what you propose. But the > first two listed requirements can be met in cursory ways: > > - the requirement that sources must be sent to one or more streams begs > the question of when you do or don't have a source. For instance, if I > mute my phone, have I removed a source or have I stopped sending the > source to a stream? Its more that there is a binding between a source and a stream, and if the source has data, it gets sent on that stream. In the case of mute, I would argue that the source has no data. > > - I believe the bit bucket is a perfectly valid sink. I can always > dispose of input from a stream by conjuring up a bit bucket sink to send > it to. It is a question of what behavior is desired by the sender. If the sender is collecting media from different sources, it needs to know that the general behavior is that all sources will be rendered. If people interpret multiple m lines to be "pick one, throw the rest in the garbage", then the sender needs to do mixing at its end. So, the strength of this incoming stream to actual sink requirement would be SHOULD, so that you could still discard a media stream, but only if you had some specific reason to do so. That is, the normal behavior would be to present everything. -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 Jan 4 16:48: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 QAA14577 for ; Fri, 4 Jan 2002 16: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 QAA07835; Fri, 4 Jan 2002 16:48: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 QAA07793 for ; Fri, 4 Jan 2002 16:48:29 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14574; Fri, 4 Jan 2002 16:48:22 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g04LlqVZ007275; Fri, 4 Jan 2002 16:47:52 -0500 (EST) Message-ID: <3C3622EB.5040707@dynamicsoft.com> Date: Fri, 04 Jan 2002 16:47:23 -0500 From: Jonathan Rosenberg 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: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] supporting just one codec at a time 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 been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -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 Jan 4 17:52: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 RAA15626 for ; Fri, 4 Jan 2002 17:52: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 RAA09589; Fri, 4 Jan 2002 17:51:55 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA09476 for ; Fri, 4 Jan 2002 17:51:50 -0500 (EST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15610; Fri, 4 Jan 2002 17:51:47 -0500 (EST) Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g04MpHZ03015; Fri, 4 Jan 2002 17:51:17 -0500 (EST) Received: from lucent.com (pctla2 [135.3.130.26]) by teton.mh.lucent.com (8.8.8+Sun/8.8.8) with ESMTP id RAA00051; Fri, 4 Jan 2002 17:51:16 -0500 (EST) Message-ID: <3C36312F.F4E4CAAA@lucent.com> Date: Fri, 04 Jan 2002 17:48:15 -0500 From: Terry L Anderson Organization: Lucent Technologies X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org References: <3C3622EB.5040707@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------AC8BF07BF7B7D127730CD650" Subject: [MMUSIC] Re: [Sip-implementors] supporting just one codec at a time 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. --------------AC8BF07BF7B7D127730CD650 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the need for > an endpoint to indicate in its SDP that it can do any one of these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll trim it to a > single list. > > The response I gave to people who asked about it, was that this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > was for, and to go read that. However, after a discussion with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > one of those alternate cdsc in the answer: > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > We would probably need to define an additional attribute in the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > > This approach may confused intermediaries that are assuming a subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal offer/answer, > the answerer has to pick a subset, but they use the simcap declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, IMHO, the only > capability problem that anyone actually has in real usage. I will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along with this, > to include an m line with the rfc2833, and then another m line with the > N codecs and the a=pickone attribute. simcap is indeed overkill for this and I like new attribute as long as we relax the requirement currently in offer-answer: "Once the offerer has sent the offer, it MUST be prepared to receive media described by that offer." If this is not relaxed the offerer cannot know which of the list of codecs to receive with and may not be able to listen with all of them until receiving the answer. Of course simcap can still be used in addition to this to indicate media that can be supported but not initially opened (e.g., rfc2833). > > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I thought it > implied approach #3 above).... comments on the various alternatives? > > -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 -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla --------------AC8BF07BF7B7D127730CD650 Content-Type: text/x-vcard; charset=us-ascii; name="tla.vcf" Content-Description: Card for Terry L Anderson Content-Disposition: attachment; filename="tla.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Anderson;Terry L tel;fax:908.582.6729 tel;work:908.582.7013 x-mozilla-html:TRUE url:http://its.lucent.com/~tla org:Lucent / Integrated Network Solutions;VoIP Access Networks version:2.1 email;internet:tla@lucent.com title:DMTS note:http://www.gti.net/tla or http://teton.mh.lucent.com/~tla (Lucent internal) adr;quoted-printable:;;Rm 2B-121=0D=0A600 Mountain Ave;Murray Hill;NJ;07974;USA x-mozilla-cpt:;-4752 fn:Terry L Anderson end:vcard --------------AC8BF07BF7B7D127730CD650-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 4 18:50: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 SAA16316 for ; Fri, 4 Jan 2002 18:50: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 SAA11125; Fri, 4 Jan 2002 18:49: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 SAA11082 for ; Fri, 4 Jan 2002 18:49:47 -0500 (EST) Received: from Mitel.COM ([216.191.234.70]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16313; Fri, 4 Jan 2002 18:49:43 -0500 (EST) Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id SAA25089; Fri, 4 Jan 2002 18:49:03 -0500 (EST) Received: from pc3002 ([134.199.77.12]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id SAA13790; Fri, 4 Jan 2002 18:49:02 -0500 (EST) Reply-To: From: "Jerry Yin" To: "'Jonathan Rosenberg'" , , , Date: Fri, 4 Jan 2002 18:49:27 -0500 Message-ID: <000401c1957a$72fce690$0c4dc786@pc3002.mitel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal In-Reply-To: <3C3622EB.5040707@dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Content-Transfer-Encoding: 7bit Subject: [MMUSIC] RE: [Sip-implementors] supporting just one codec at a time 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 there, After I read the simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t), I found that it is not backwards compatible with the SDP (RFC 2327). Here's my comments. 1. the rtpmap's format in RFC 2327 is a=rtpmap: /[/]. While in simcap, it is : a=rtpmap: telephone-event Where is the "telephone-event" defined as an encoding name? If the UA is implemented according to RFC 2327, how can it talk to the UAs implemented according to the simcap? 2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the media attributes already. I don't know why it is necessary to define a new attributes of "a=cdsc" and "a=cpar". There are some redundant information here, I think. 3. If we want to describe a subset of capabilities among all capabilities the SDP claimed, we can simply introduce one new attribute to describe the subset. For example, a=subset subset_codec_number : total_codec_number. This way, even some UAs don't understand a = subset, they still can talk with the one supports this attribute by at list one media streaming. Here's an example: v=0 o=- 25678 753849 IN IP4 128.96.41.1 s=- c=IN IP4 128.96.41.1 t=0 0 m=audio 3456 RTP/AVP 96 97 98 a=rtpmap:96 L8/8000 a=rtpmap:97 L16/8000 a=rtpmap:98 L16/11025/2 a=subset 2:3 m=video 3458 RTP/AVP 26 31 a=rtpmap:26 JPEG/90000 a=rtpmap:31 H261/90000 a=subset 1:2 This packet means the sender can support two audio streams among three different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or H261. Above all, it is not a good idea to introduce new headers only if 1) backwards compatible, 2) really necessary and can solve problems, 3) easy to implement. Thanks, Jerry Yin > -----Original Message----- > From: sip-implementors-admin@cs.columbia.edu > [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of Jonathan > Rosenberg > Sent: Friday, January 04, 2002 4:47 PM > To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org > Subject: [Sip-implementors] supporting just one codec at a time > > > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed > addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the > need for > an endpoint to indicate in its SDP that it can do any one of > these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll > trim it to a > single list. > > The response I gave to people who asked about it, was that > this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sd > p-simcap-04.txt) > was for, and to go read that. However, after a discussion > with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This > information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of > simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the > counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake > somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe > entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU > with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer > could pick > one of those alternate cdsc in the answer: > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > > We would probably need to define an additional attribute in > the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > > This approach may confused intermediaries that are assuming a > subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with > offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal > offer/answer, > the answerer has to pick a subset, but they use the simcap > declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along > with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly > change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an > RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of > the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, > IMHO, the only > capability problem that anyone actually has in real usage. I > will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along > with this, > to include an m line with the rfc2833, and then another m > line with the > N codecs and the a=pickone attribute. > > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I > thought it > implied approach #3 above).... comments on the various alternatives? > > -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 Fri Jan 4 21:04:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17361 for ; Fri, 4 Jan 2002 21:04: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 VAA14613; Fri, 4 Jan 2002 21: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 VAA14579 for ; Fri, 4 Jan 2002 21:04:41 -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 VAA17356 for ; Fri, 4 Jan 2002 21:04:38 -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 g0524Do21407; Fri, 4 Jan 2002 21:04:13 -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 AAA00729 (AUTH pkyzivat); Fri, 4 Jan 2002 21:06:42 -0500 (EST) Message-ID: <3C365E0C.8ED354D3@cisco.com> Date: Fri, 04 Jan 2002 20:59:40 -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: Flemming Andreasen CC: Jonathan Rosenberg , mmusic@ietf.org, confctrl@ISI.EDU Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer References: <3C2342E1.83EB1CFD@cisco.com> <3C27AC61.5010909@dynamicsoft.com> <3C35E72D.7A9D3FB6@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'm obviously doing a poor job of expressing myself clearly, however I > believe we have agreed on the underlying issue (that all codecs listed in a > sendrecv media stream must be supported for send and receive in both the > offer and answer). Given that, I'm happy to leave this for now and just take > a look at the next version of the draft. Finally I think I understand the point you are trying to make: If an offerer intends to send, and includes several codecs in the offer of a sendrecv stream, then it should be prepared to send on whichever of them are chosen by the answerer. This is a very different use of the phrase "be prepared" than for an offerer to "be prepared" to receive early media using any of the mentioned codecs. Even so, there is opportunity to fudge. There may simply be things that the offerer will send on one codec and simply choose not to send on another codec. Whether that is reasonable behavior will vary from case to case. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 4 21:26: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 VAA17460 for ; Fri, 4 Jan 2002 21:26: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 VAA14885; Fri, 4 Jan 2002 21:26: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 VAA14854 for ; Fri, 4 Jan 2002 21:26:20 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17457 for ; Fri, 4 Jan 2002 21:26:17 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g052QIVZ007394; Fri, 4 Jan 2002 21:26:18 -0500 (EST) Message-ID: <3C36642C.5040107@dynamicsoft.com> Date: Fri, 04 Jan 2002 21:25:48 -0500 From: Jonathan Rosenberg 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: Paul Kyzivat CC: Flemming Andreasen , mmusic@ietf.org, confctrl@ISI.EDU Subject: Re: [MMUSIC] Re: resolving open issues in offer/answer References: <3C365E0C.8ED354D3@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Flemming Andreasen wrote: > >>I'm obviously doing a poor job of expressing myself clearly, however I >>believe we have agreed on the underlying issue (that all codecs listed >> > in a > >>sendrecv media stream must be supported for send and receive in both >> > the > >>offer and answer). Given that, I'm happy to leave this for now and >> > just take > >>a look at the next version of the draft. >> > > Finally I think I understand the point you are trying to make: > > If an offerer intends to send, and includes several codecs in the offer > of a sendrecv stream, then it should be prepared to send on whichever of > them are chosen by the answerer. OK, I will use this text in the spec. Can we move on from this item now? -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 Jan 4 21:51:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18597 for ; Fri, 4 Jan 2002 21:51: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 VAA15576; Fri, 4 Jan 2002 21:51: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 VAA15540 for ; Fri, 4 Jan 2002 21:51:11 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18594 for ; Fri, 4 Jan 2002 21:51:07 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.84]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g052p8VZ007402; Fri, 4 Jan 2002 21:51:09 -0500 (EST) Message-ID: <3C3669FE.5040403@dynamicsoft.com> Date: Fri, 04 Jan 2002 21:50:38 -0500 From: Jonathan Rosenberg 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: Flemming Andreasen CC: mmusic@ietf.org Subject: Re: [MMUSIC] resolving open issues in offer/answer References: <3C35ED5B.A40B3E98@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > >>I will admit that changing SSRC might >>introduce some confusion into systems; I welcome inputs on specific >>problems it might cause. >> >> > > Again, I think it is important to have some flexibility surrounding the > use of such > an SSRC attribute, and see it as an optimization hint as opposed to > enforcing strict > rules. > > As far as problems go, SRTP security contexts (which key off the SSRC) > would seem to > be potentially troublesome. That is true. Paul K. also pointed out that it is RTP specific. Let me summarize where we are. The problem was how to know that it is safe to "unload" a codec after a change. This needs to be syncrhonized with some event in the media stream. The proposals we've entertained: 1. use different ssrc once new codecs are in use CONS requres SRTP re-keying on change in codecs. SSRCs can also change due to collisions Requires a new SDP attribute RTP specific sender oriented (that is, if B needs an indication of the change, its up to A to support it, since the sender chooses the SSRC) PROS also helps disambiguage multiple media streams to the same port in case the offer is in a forked invite 2. use different port once new codecs are in use CONS may require new resource reservations requires SRTP rekeying using transport IDs as application IDs is a general bad idea because of nat (although I can't think of a specific issue here) PROS not RTP specific doesn't require any new SDP attributes 3. use different payload type number CONS doesn't work with static payload types implementations don't support changing pti for the same codec may exhaust limited dynamic PT space PROS no impact on resource reservation no new SDP attributes no impact on SRTP rekeying 4. use a timer; just unload the old codec after 1 minute CONS not exact kludgey PROS requires no new SDP attributes no impact on resource reservation not rtp specific no impact on SRTP rekeying I think its probably provable that no solution can achieve all of the desired goals here. Using a specific indicator in the media stream means it has to be something in the RTP packet. Of the headers in the RTP packet, most cannot be used at all (version, padding, extension bit, csrc count, marker, sequence number, timestamp), two are discussed above (ssrc, pti), and another possibility is to define an extension that would include an identifier. I think an RTP extension just for this purpose is overkill. Then, there are things in the UDP header - the destination port is discussed above. Source port cannot be used because of nat. Then, there is IP header. We could use different destination IP addresses, but there are the same issues as separate ports above, and it would require multi-homed hosts. Different source addresses doesn't work with nat. So, we have provably exhausted the set of in-packet indicators. Then, there is a non-packet indicator, which is the timer above. THus, we've got everything listed, and nothing seems ideal. I think the best solution is to punt it ;). Seriously, though, this may be a non-issue in many implementations, where there is no notion of unloading a codec. If an implementation needs to know when its safe to stop being prepared to receive with a codec, it can employ either the timer approach or the port change mechanism, both are local implementation choices that require no additional protocol semantics. So, we can describe both, discuss the issues, and leave it at that. 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 Fri Jan 4 21:56: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 VAA18629 for ; Fri, 4 Jan 2002 21:56: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 VAA15740; Fri, 4 Jan 2002 21:55: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 VAA15632 for ; Fri, 4 Jan 2002 21:54:57 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18623; Fri, 4 Jan 2002 21:54:53 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g052sNE04462; Fri, 4 Jan 2002 21:54:23 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g052sLA13381; Fri, 4 Jan 2002 21:54:22 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jan 2002 21:52:45 -0500 Message-ID: <4D79C746863DD51197690002A52CDA000102ADD0@zcard0kc.ca.nortel.com> From: "Tom-PT Taylor" To: "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: RE: [MMUSIC] supporting just one codec at a time Date: Fri, 4 Jan 2002 21:52:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19594.14C2BE50" 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_01C19594.14C2BE50 Content-Type: text/plain; charset="iso-8859-1" a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our model nicely. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 04, 2002 4:47 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [MMUSIC] supporting just one codec at a time Folks, I've been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -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_01C19594.14C2BE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [MMUSIC] supporting just one codec at a time

a=3Dpickone corresponds to the Megaco ReserveValue = attribute, so it fits our model nicely.

-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, January 04, 2002 4:47 PM
To: sip@ietf.org; sip-implementors@cs.columbia.edu; = mmusic@ietf.org
Subject: [MMUSIC] supporting just one codec at a = time


Folks,

I've been combing through the sip-implementors and = sip lists, looking
for open issues that need resolution, or comments = that needed addressing
in the specification. This is the source of much of = my spamming on
sip-implementors....

An issue that has arisen time and time and time = again, is the need for
an endpoint to indicate in its SDP that it can do = any one of these three
codecs, but can only do one at a time, that is, it = doesn't support
dynamically changing codecs on the fly. Since the = question has been
asked 1/2 dozen times on sip-implementors, and = concerns both sip and
mmusic, I have cross posted. If the thread takes off = we'll trim it to a
single list.

The response I gave to people who asked about it, was = that this was what
simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mm= usic-sdp-simcap-04.txt)
was for, and to go read that. However, after a = discussion with Flemming,
it appears I misinterpreted that specification. It = is merely a
declaration of the codes that an endpoint can = support. This information
would be used in subsequent offer/answer exchanges, = so that a UA can
make an offer without having to guess whether it = would or wouldn't be
accepted. I was under the false impression that the = point of simcap was
to, in fact, solve this particular problem of = one-codec-at-a-time for
the initial exchange.

So, we are faced with this gap of how to handle this = problem. I see a
few solutions:

1. Use a three-way handshake in SIP, using = offer/counter-offer/answer.

The offer would list ALL the codecs the UA can do, = the counter-offer is
the subset that the other UA can do, and the answer = can reduce it
further to just a few.

This solution would require us to define this 3-way = handshake somewhere;
that is still being debated as an open issue. Bill = has included this
already in manyfolks, partly to solve this problem = (or maybe entirely to
solve this problem).

2. Define a backwards compatible usage of simcap to = modify the
offer-answer exchange.

The offer would contain an m line with a single codec = choice (in this
particular case where it can do only one a time), = but the offer would
include simcap attributes indicating support for = other codecs. The
answerer could choose from amongst those codecs in = formulating the
answer. So, for example:

Offer:

m=3Daudio 8778 RTP/AVP 0 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76

This offer means that the offerer is definitely using = PCMU with someone
that doesn't understand simcap, but is indicating = they can also do
codecs 1 and 2 (and each of them with rfc2833). The = answerer could pick
one of those alternate cdsc in the answer:

m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


We would probably need to define an additional = attribute in the SDP that
indicates that this "simcap effects the m line = selection" semantic is
being followed.

This approach may confused intermediaries that are = assuming a subset of
codecs in the answer.

3. Define a sort-of backwards compatible usage of = simcap with offer/answer

In this model, the offerer lists all codecs they can = do in the offer.
They include simcap declarations as well. As with = normal offer/answer,
the answerer has to pick a subset, but they use the = simcap declarations
to help them pick a subset which is an allowed = capability. So, in the
example above where the caller can do codecs 0,2,3,4 = along with 76, but
only ONE of 0,2,3,4 at a time, the O/A would look = like this:

OFFER:

m=3Daudio 8778 RTP/AVP 0 1 2 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76

ANSWER:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


If, however, the UAS doesn't understand simcap, its = possible that
they'll return an SDP listing all four codecs, and = possibly change them
on the fly. That can be fixed, in general, by = another re-invite which
lists only a single codec. This will work, but might = cause an RTT worth
of media to be sent using a codec different from the = one the UAC
"loaded" into the DSP.

4. Declare that simcap is overkill for this one = problem, and define a
single attribute, a=3Dpickone, which says to choose = only one of the codecs
in the m line.

The "I can do one of N, but only one at a = time" problem, IMHO, the only
capability problem that anyone actually has in real = usage. I will note
that, in fact, this is the only capabilities = question ever asked on
sip-implementors.

A single attribute would easily solve it. If you want = to do rfc2833
along with any one of N other codecs, you could use = fid along with this,
to include an m line with the rfc2833, and then = another m line with the
N codecs and the a=3Dpickone attribute.


One way or another, we need to solve this problem. My = apologies for
bringing this up so late, but I had thought it was = solved (I thought it
implied approach #3 above).... comments on the = various alternatives?

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


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

------_=_NextPart_001_01C19594.14C2BE50-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 7 10:46: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 KAA17866 for ; Mon, 7 Jan 2002 10:46: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 KAA10259; Mon, 7 Jan 2002 10:46: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 KAA10211 for ; Mon, 7 Jan 2002 10:46:03 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17859; Mon, 7 Jan 2002 10:46:01 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FjUA14635; Mon, 7 Jan 2002 10:45:31 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g07FjEF22823; Mon, 7 Jan 2002 15:45:15 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jan 2002 15:44:02 -0000 Message-ID: From: "Mark Watson" To: "Tom-PT Taylor", "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: RE: [Sip] RE: [MMUSIC] supporting just one codec at a time Date: Mon, 7 Jan 2002 15:43:57 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19792.1E9A4290" 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_01C19792.1E9A4290 Content-Type: text/plain; charset="iso-8859-1" Generalising: a=pickn: meaning "pick any 'n' codecs from the list on the m= line, so long as the ones from are included in that n" would allow you to encode things like 'I support G.711 *or* G.726 and I support RFC2833 with either': There are a bunch of other ways to specify general sub-sets of the , for example a list of n-bit bit masks, where n is the size of the fmt list etc. I can imagine cases where a UA supports several compressed codecs, only one at a time, but supports upspeeding to G.711 and RFC2833 with all of them. The offer/counter-offer/answer case is always needed for whenever the UAS does not support any new SDP attribute such as that above. In this case you have the possibility of 1 RTT of lost media, as described below. ...Mark -----Original Message----- From: Taylor, Tom-PT [CAR:B800:EXCH] Sent: 05 January 2002 02:53 To: 'Jonathan Rosenberg'; sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [Sip] RE: [MMUSIC] supporting just one codec at a time a=pickone corresponds to the Megaco ReserveValue attribute, so it fits our model nicely. -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, January 04, 2002 4:47 PM To: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [MMUSIC] supporting just one codec at a time Folks, I've been combing through the sip-implementors and sip lists, looking for open issues that need resolution, or comments that needed addressing in the specification. This is the source of much of my spamming on sip-implementors.... An issue that has arisen time and time and time again, is the need for an endpoint to indicate in its SDP that it can do any one of these three codecs, but can only do one at a time, that is, it doesn't support dynamically changing codecs on the fly. Since the question has been asked 1/2 dozen times on sip-implementors, and concerns both sip and mmusic, I have cross posted. If the thread takes off we'll trim it to a single list. The response I gave to people who asked about it, was that this was what simcap (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx t) was for, and to go read that. However, after a discussion with Flemming, it appears I misinterpreted that specification. It is merely a declaration of the codes that an endpoint can support. This information would be used in subsequent offer/answer exchanges, so that a UA can make an offer without having to guess whether it would or wouldn't be accepted. I was under the false impression that the point of simcap was to, in fact, solve this particular problem of one-codec-at-a-time for the initial exchange. So, we are faced with this gap of how to handle this problem. I see a few solutions: 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. The offer would list ALL the codecs the UA can do, the counter-offer is the subset that the other UA can do, and the answer can reduce it further to just a few. This solution would require us to define this 3-way handshake somewhere; that is still being debated as an open issue. Bill has included this already in manyfolks, partly to solve this problem (or maybe entirely to solve this problem). 2. Define a backwards compatible usage of simcap to modify the offer-answer exchange. The offer would contain an m line with a single codec choice (in this particular case where it can do only one a time), but the offer would include simcap attributes indicating support for other codecs. The answerer could choose from amongst those codecs in formulating the answer. So, for example: Offer: m=audio 8778 RTP/AVP 0 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 This offer means that the offerer is definitely using PCMU with someone that doesn't understand simcap, but is indicating they can also do codecs 1 and 2 (and each of them with rfc2833). The answerer could pick one of those alternate cdsc in the answer: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event We would probably need to define an additional attribute in the SDP that indicates that this "simcap effects the m line selection" semantic is being followed. This approach may confused intermediaries that are assuming a subset of codecs in the answer. 3. Define a sort-of backwards compatible usage of simcap with offer/answer In this model, the offerer lists all codecs they can do in the offer. They include simcap declarations as well. As with normal offer/answer, the answerer has to pick a subset, but they use the simcap declarations to help them pick a subset which is an allowed capability. So, in the example above where the caller can do codecs 0,2,3,4 along with 76, but only ONE of 0,2,3,4 at a time, the O/A would look like this: OFFER: m=audio 8778 RTP/AVP 0 1 2 76 a=rtpmap:76 telephone-event a=sqn:0 a=cdsc: 1 audio RTP/AVP 0 76 a=cdsc: 3 audio RTP/AVP 1 76 a=cdsc: 5 audio RTP/AVP 2 76 ANSWER: m=audio 7554 RTP/AVP 1 76 a=rtpmap:76 telephone-event If, however, the UAS doesn't understand simcap, its possible that they'll return an SDP listing all four codecs, and possibly change them on the fly. That can be fixed, in general, by another re-invite which lists only a single codec. This will work, but might cause an RTT worth of media to be sent using a codec different from the one the UAC "loaded" into the DSP. 4. Declare that simcap is overkill for this one problem, and define a single attribute, a=pickone, which says to choose only one of the codecs in the m line. The "I can do one of N, but only one at a time" problem, IMHO, the only capability problem that anyone actually has in real usage. I will note that, in fact, this is the only capabilities question ever asked on sip-implementors. A single attribute would easily solve it. If you want to do rfc2833 along with any one of N other codecs, you could use fid along with this, to include an m line with the rfc2833, and then another m line with the N codecs and the a=pickone attribute. One way or another, we need to solve this problem. My apologies for bringing this up so late, but I had thought it was solved (I thought it implied approach #3 above).... comments on the various alternatives? -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_01C19792.1E9A4290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Sip] RE: [MMUSIC] supporting just one codec at a = time

Generalising:

a=3Dpickn: <n> <fmt list>

meaning "pick any 'n' codecs from the list on = the m=3D line, so long as the ones from <fmt list> are included = in that n" would allow you to encode things like 'I support G.711 = *or* G.726 and I support RFC2833 with either':

There are a bunch of other ways to specify general = sub-sets of the <fmt list>, for example a list of n-bit bit = masks, where n is the size of the fmt list etc.

I can imagine cases where a UA supports several = compressed codecs, only one at a time, but supports upspeeding to G.711 = and RFC2833 with all of them.

The offer/counter-offer/answer case is always needed = for whenever the UAS does not support any new SDP attribute such as = that above. In this case you have the possibility of 1 RTT of lost = media, as described below.

...Mark

-----Original Message-----
From: Taylor, Tom-PT [CAR:B800:EXCH]
Sent: 05 January 2002 02:53
To: 'Jonathan Rosenberg'; sip@ietf.org; = sip-implementors@cs.columbia.edu; mmusic@ietf.org
Subject: [Sip] RE: [MMUSIC] supporting just one = codec at a time


a=3Dpickone corresponds to the Megaco ReserveValue = attribute, so it fits our model nicely.
-----Original Message-----
From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]
Sent: Friday, January 04, 2002 4:47 PM
To: sip@ietf.org; sip-implementors@cs.columbia.edu; = mmusic@ietf.org
Subject: [MMUSIC] supporting just one codec at a = time


Folks,
I've been combing through the sip-implementors and = sip lists, looking
for open issues that need resolution, or comments = that needed addressing
in the specification. This is the source of much of = my spamming on
sip-implementors....
An issue that has arisen time and time and time = again, is the need for
an endpoint to indicate in its SDP that it can do = any one of these three
codecs, but can only do one at a time, that is, it = doesn't support
dynamically changing codecs on the fly. Since the = question has been
asked 1/2 dozen times on sip-implementors, and = concerns both sip and
mmusic, I have cross posted. If the thread takes off = we'll trim it to a
single list.
The response I gave to people who asked about it, = was that this was what
simcap
(http://www.ietf.org/internet-drafts/draft-andreasen-mm= usic-sdp-simcap-04.txt)
was for, and to go read that. However, after a = discussion with Flemming,
it appears I misinterpreted that specification. It = is merely a
declaration of the codes that an endpoint can = support. This information
would be used in subsequent offer/answer exchanges, = so that a UA can
make an offer without having to guess whether it = would or wouldn't be
accepted. I was under the false impression that the = point of simcap was
to, in fact, solve this particular problem of = one-codec-at-a-time for
the initial exchange.
So, we are faced with this gap of how to handle this = problem. I see a
few solutions:
1. Use a three-way handshake in SIP, using = offer/counter-offer/answer.
The offer would list ALL the codecs the UA can do, = the counter-offer is
the subset that the other UA can do, and the answer = can reduce it
further to just a few.
This solution would require us to define this 3-way = handshake somewhere;
that is still being debated as an open issue. Bill = has included this
already in manyfolks, partly to solve this problem = (or maybe entirely to
solve this problem).
2. Define a backwards compatible usage of simcap to = modify the
offer-answer exchange.
The offer would contain an m line with a single = codec choice (in this
particular case where it can do only one a time), = but the offer would
include simcap attributes indicating support for = other codecs. The
answerer could choose from amongst those codecs in = formulating the
answer. So, for example:
Offer:
m=3Daudio 8778 RTP/AVP 0 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76
This offer means that the offerer is definitely = using PCMU with someone
that doesn't understand simcap, but is indicating = they can also do
codecs 1 and 2 (and each of them with rfc2833). The = answerer could pick
one of those alternate cdsc in the answer:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


We would probably need to define an additional = attribute in the SDP that
indicates that this "simcap effects the m line = selection" semantic is
being followed.
This approach may confused intermediaries that are = assuming a subset of
codecs in the answer.
3. Define a sort-of backwards compatible usage of = simcap with offer/answer
In this model, the offerer lists all codecs they can = do in the offer.
They include simcap declarations as well. As with = normal offer/answer,
the answerer has to pick a subset, but they use the = simcap declarations
to help them pick a subset which is an allowed = capability. So, in the
example above where the caller can do codecs 0,2,3,4 = along with 76, but
only ONE of 0,2,3,4 at a time, the O/A would look = like this:
OFFER:
m=3Daudio 8778 RTP/AVP 0 1 2 76
a=3Drtpmap:76 telephone-event
a=3Dsqn:0
a=3Dcdsc: 1 audio RTP/AVP 0 76
a=3Dcdsc: 3 audio RTP/AVP 1 76
a=3Dcdsc: 5 audio RTP/AVP 2 76
ANSWER:
m=3Daudio 7554 RTP/AVP 1 76
a=3Drtpmap:76 telephone-event


If, however, the UAS doesn't understand simcap, its = possible that
they'll return an SDP listing all four codecs, and = possibly change them
on the fly. That can be fixed, in general, by = another re-invite which
lists only a single codec. This will work, but might = cause an RTT worth
of media to be sent using a codec different from the = one the UAC
"loaded" into the DSP.
4. Declare that simcap is overkill for this one = problem, and define a
single attribute, a=3Dpickone, which says to choose = only one of the codecs
in the m line.
The "I can do one of N, but only one at a = time" problem, IMHO, the only
capability problem that anyone actually has in real = usage. I will note
that, in fact, this is the only capabilities = question ever asked on
sip-implementors.
A single attribute would easily solve it. If you = want to do rfc2833
along with any one of N other codecs, you could use = fid along with this,
to include an m line with the rfc2833, and then = another m line with the
N codecs and the a=3Dpickone attribute.


One way or another, we need to solve this problem. My = apologies for
bringing this up so late, but I had thought it was = solved (I thought it
implied approach #3 above).... comments on the = various alternatives?
-Jonathan R.
--
Jonathan D. Rosenberg, = Ph.D.            = 72 Eagle Rock Avenue
Chief = Scientist          &nb= sp;           &nb= sp;  First Floor
dynamicsoft        &nbs= p;           &nbs= p;        East Hanover, NJ 07936 =
jdrosen@dynamicsoft.com      &nbs= p;          FAX: (973) = 952-5050
http://www.jdrosen.net    &nbs= p;           &nbs= p; PH:  (973) 952-5000
http://www.dynamicsoft.com


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

------_=_NextPart_001_01C19792.1E9A4290-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 8 10:36: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 KAA25872 for ; Tue, 8 Jan 2002 10:36: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 KAA04253; Tue, 8 Jan 2002 10:36: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 KAA04218 for ; Tue, 8 Jan 2002 10:36: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 KAA25852 for ; Tue, 8 Jan 2002 10:35:58 -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 HAA28140; Tue, 8 Jan 2002 07:35:22 -0800 (PST) Message-ID: <3C3B11DB.32C803E8@cisco.com> Date: Tue, 08 Jan 2002 10:35:55 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [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] resolving open issues in offer/answer References: <3C35ED5B.A40B3E98@cisco.com> <3C3669FE.5040403@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: > > > > > >>I will admit that changing SSRC might > >>introduce some confusion into systems; I welcome inputs on specific > >>problems it might cause. > >> > >> > > > > Again, I think it is important to have some flexibility surrounding the > > use of such > > an SSRC attribute, and see it as an optimization hint as opposed to > > enforcing strict > > rules. > > > > As far as problems go, SRTP security contexts (which key off the SSRC) > > would seem to > > be potentially troublesome. > > That is true. Paul K. also pointed out that it is RTP specific. > > Let me summarize where we are. The problem was how to know that it is > safe to "unload" a codec after a change. This needs to be syncrhonized > with some event in the media stream. The proposals we've entertained: > > 1. use different ssrc once new codecs are in use > > CONS > requres SRTP re-keying on change in codecs. > SSRCs can also change due to collisions > Requires a new SDP attribute > RTP specific > sender oriented (that is, if B needs an indication of the change, its > up to A to support it, since the sender chooses the SSRC) > > PROS > > also helps disambiguage multiple media streams to the same port in > case the offer is in a forked invite > > 2. use different port once new codecs are in use > > CONS > > may require new resource reservations > requires SRTP rekeying > using transport IDs as application IDs is a general bad idea because > of nat (although I can't think of a specific issue here) > > PROS > > not RTP specific > doesn't require any new SDP attributes > > 3. use different payload type number > > CONS > > doesn't work with static payload types > implementations don't support changing pti for the same codec > may exhaust limited dynamic PT space > > PROS > > no impact on resource reservation > no new SDP attributes > no impact on SRTP rekeying > > 4. use a timer; just unload the old codec after 1 minute > > CONS > > not exact > kludgey > > PROS > > requires no new SDP attributes > no impact on resource reservation > not rtp specific > no impact on SRTP rekeying > > I think its probably provable that no solution can achieve all of the > desired goals here. Using a specific indicator in the media stream means > it has to be something in the RTP packet. Of the headers in the RTP > packet, most cannot be used at all (version, padding, extension bit, > csrc count, marker, sequence number, timestamp), two are discussed above > (ssrc, pti), and another possibility is to define an extension that > would include an identifier. I think an RTP extension just for this > purpose is overkill. Maybe, however as you noted earlier, we also have the related problem of correlating multiple media streams with multiple answers, e.g. in the case of SIP forking. > Then, there are things in the UDP header - the > destination port is discussed above. Source port cannot be used because > of nat. Then, there is IP header. We could use different destination IP > addresses, but there are the same issues as separate ports above, and it > would require multi-homed hosts. Different source addresses doesn't work > with nat. So, we have provably exhausted the set of in-packet > indicators. Then, there is a non-packet indicator, which is the timer > above. THus, we've got everything listed, and nothing seems ideal. > > I think the best solution is to punt it ;). Seriously, though, this may > be a non-issue in many implementations, where there is no notion of > unloading a codec. If an implementation needs to know when its safe to > stop being prepared to receive with a codec, it can employ either the > timer approach or the port change mechanism, both are local > implementation choices that require no additional protocol semantics. > So, we can describe both, discuss the issues, and leave it at that. > Might as well describe the payload type change approach as well then since it seems to have the fewest problems as long as it's optional. -- Flemming > > 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 -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 8 14:58: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 OAA08043 for ; Tue, 8 Jan 2002 14:58: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 OAA18640; Tue, 8 Jan 2002 14:56: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 OAA18609 for ; Tue, 8 Jan 2002 14:56:29 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07938 for ; Tue, 8 Jan 2002 14:56:26 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g08JtwF05074 for ; Tue, 8 Jan 2002 11:55:58 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn2-213.cisco.com [10.21.112.213]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAP52269; Tue, 8 Jan 2002 11:55:29 -0800 (PST) Message-Id: <4.3.2.7.2.20020108115328.07337c00@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jan 2002 11:53:58 -0800 To: mmusic@ietf.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Fwd: [MSEC] MIKEY mapping of keys to steams -- possible vulnerability 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 >Delivered-To: msec@pairlist.net >Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org >From: Brian Weis >X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) >X-Accept-Language: en >To: fredrik.lindholm@era.ericsson.se, elisabetta.carrara@era.ericsson.se, > jari.arkko@ericsson.com, mats.naslund@era.ericsson.se >Cc: msec@securemulticast.org >Subject: [MSEC] MIKEY mapping of keys to steams -- possible vulnerability >Sender: msec-admin@securemulticast.org >X-BeenThere: msec@securemulticast.org >X-Mailman-Version: 2.0 >List-Help: >List-Post: >List-Subscribe: , > >List-Id: IETF Multicast Security list >List-Unsubscribe: , > >List-Archive: >Date: Mon, 07 Jan 2002 12:04:04 -0800 > >I have a question on how MIKEY accurately maintains a mapping of keys to >audio/video streams in an SDP specification. I've given my understanding >of how this happens so you can check my assumptions, and then I suggest >a possibly vulnerability. > >MIKEY specifies a new concept of "crypto session id" which it uses to >label media streams which are later defined in an SDP description The >crypto session id is a logical identity where the first media session >("m=") statement is associated with the first crypto session id, the >second media session statement is associated with the second crypto >session id, etc. (This seems clear from section 6. of MIKEY.) > >The format of the crypto session id is specified in section A.1. The >concept of the MCS ID is defined to be an 80-bit random number which >doesn't describe the media session at all, and I can't tell how the CS >IDs are defined but I see nothing which is mappable to the actual media >streams. > >MIKEY protects the "a=keymgmt-data" data such that tampering can be >detected within the key management data. > >But MIKEY cannot detect if the "m=" statements in the SDP description >have been replaced or otherwise modified. To illustrate my point, here >is the example in the MIKEY document: > > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > >Suppose this was modified by a man-in-the-middle and the SDP was changed >to this: > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > | CS 2 < m=audio 49170 RTP/SAVP 31 > >The keys in keymgmt-data will be correctly transmitted in the MIKEY >description, but applied to the wrong media streams. > >This could be considered a DoS attack. In the case of a multicast group, >it's a more serious attack: if a dishonest group member (holding the >encryption keys) changes the SDP before other group members see it, he >can source different media streams which match the new SDP definition. >These will be authenticated in MIKEY and accepted as the valid streams, >when in fact they are not what the person who sent the MIKEY definition >intended. > >I realize that MIKEY did not intend to protect the "m=" statements in >any way. But it seems to me that the implicit references to the rest of >the SDP definition affects the validity of MIKEY. > >One way to solve this might be to include something in the CS ID so that >the media can be verified (e.g., a hash of the "m=" statement). But that >doesn't handle all of the dependencies on the SDP statements. MIKEY is >also dependent on the "c=" statement defining the actual multicast >address. > >Another solution would be to require that MIKEY be used in conjunction >with a separate authentication system which authenticates the entire SDP >definition. (For example, SIP defines some authentication using PGP >although I've heard comments that on one actually uses it.) This seems >to me to be the safest approach, but it is too bad that MIKEY would be >dependent on other systems. > >I'm anxious to hear your comments. > >Thanks, >Brian >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 8 16:33: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 QAA11019 for ; Tue, 8 Jan 2002 16: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 QAA23453; Tue, 8 Jan 2002 16:33: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 QAA23416 for ; Tue, 8 Jan 2002 16:33: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 QAA11009; Tue, 8 Jan 2002 16:33:30 -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 NAA08506; Tue, 8 Jan 2002 13:32:47 -0800 (PST) Message-ID: <3C3B65A0.A88A474B@cisco.com> Date: Tue, 08 Jan 2002 16:33:21 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] supporting just one codec at a time References: <3C3622EB.5040707@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: > Folks, > > I've been combing through the sip-implementors and sip lists, looking > for open issues that need resolution, or comments that needed addressing > in the specification. This is the source of much of my spamming on > sip-implementors.... > > An issue that has arisen time and time and time again, is the need for > an endpoint to indicate in its SDP that it can do any one of these three > codecs, but can only do one at a time, that is, it doesn't support > dynamically changing codecs on the fly. Since the question has been > asked 1/2 dozen times on sip-implementors, and concerns both sip and > mmusic, I have cross posted. If the thread takes off we'll trim it to a > single list. > > The response I gave to people who asked about it, was that this was what > simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > was for, and to go read that. However, after a discussion with Flemming, > it appears I misinterpreted that specification. It is merely a > declaration of the codes that an endpoint can support. This information > would be used in subsequent offer/answer exchanges, so that a UA can > make an offer without having to guess whether it would or wouldn't be > accepted. I was under the false impression that the point of simcap was > to, in fact, solve this particular problem of one-codec-at-a-time for > the initial exchange. > > So, we are faced with this gap of how to handle this problem. I see a > few solutions: > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > The offer would list ALL the codecs the UA can do, the counter-offer is > the subset that the other UA can do, and the answer can reduce it > further to just a few. > > This solution would require us to define this 3-way handshake somewhere; > that is still being debated as an open issue. Bill has included this > already in manyfolks, partly to solve this problem (or maybe entirely to > solve this problem). > > 2. Define a backwards compatible usage of simcap to modify the > offer-answer exchange. > > The offer would contain an m line with a single codec choice (in this > particular case where it can do only one a time), but the offer would > include simcap attributes indicating support for other codecs. The > answerer could choose from amongst those codecs in formulating the > answer. So, for example: > > Offer: > > m=audio 8778 RTP/AVP 0 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > > This offer means that the offerer is definitely using PCMU with someone > that doesn't understand simcap, but is indicating they can also do > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > one of those alternate cdsc in the answer: That's a slight overloading of the simcap semantics which doesn't define any kind of grouping of capabilities. Normal usage of simcap would only list a given capability once (per media stream at least). If you wanted to express something like the above, you would really want to define a new attribute that could describe allowable combinations of codecs, however that level of expressiveness was outside the scope of the simcap specification. > > > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > We would probably need to define an additional attribute in the SDP that > indicates that this "simcap effects the m line selection" semantic is > being followed. > Right. > > This approach may confused intermediaries that are assuming a subset of > codecs in the answer. > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > In this model, the offerer lists all codecs they can do in the offer. > They include simcap declarations as well. As with normal offer/answer, > the answerer has to pick a subset, but they use the simcap declarations > to help them pick a subset which is an allowed capability. So, in the > example above where the caller can do codecs 0,2,3,4 along with 76, but > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > OFFER: > > m=audio 8778 RTP/AVP 0 1 2 76 > a=rtpmap:76 telephone-event > a=sqn:0 > a=cdsc: 1 audio RTP/AVP 0 76 > a=cdsc: 3 audio RTP/AVP 1 76 > a=cdsc: 5 audio RTP/AVP 2 76 > Again, this is a slight overloading of the simcap semantics. > > ANSWER: > m=audio 7554 RTP/AVP 1 76 > a=rtpmap:76 telephone-event > > If, however, the UAS doesn't understand simcap, its possible that > they'll return an SDP listing all four codecs, and possibly change them > on the fly. That can be fixed, in general, by another re-invite which > lists only a single codec. This will work, but might cause an RTT worth > of media to be sent using a codec different from the one the UAC > "loaded" into the DSP. > > 4. Declare that simcap is overkill for this one problem, and define a > single attribute, a=pickone, which says to choose only one of the codecs > in the m line. > > The "I can do one of N, but only one at a time" problem, IMHO, the only > capability problem that anyone actually has in real usage. I will note > that, in fact, this is the only capabilities question ever asked on > sip-implementors. > > A single attribute would easily solve it. If you want to do rfc2833 > along with any one of N other codecs, you could use fid along with this, > to include an m line with the rfc2833, and then another m line with the > N codecs and the a=pickone attribute. > However that would require use of multiple ports which could lead to multiple resource reservations. Also, - fid cannot be added by the answerer if the offer didn't include it due to the media stream matching rules - if fid is included in the offer, but not supported by the answerer, the handling may not be all that graceful. -- Flemming > > One way or another, we need to solve this problem. My apologies for > bringing this up so late, but I had thought it was solved (I thought it > implied approach #3 above).... comments on the various alternatives? > > -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 Tue Jan 8 16:35: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 QAA11060 for ; Tue, 8 Jan 2002 16:35:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA23568; Tue, 8 Jan 2002 16:35: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 QAA23530 for ; Tue, 8 Jan 2002 16:35:02 -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 QAA11049; Tue, 8 Jan 2002 16:34:57 -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 NAA09398; Tue, 8 Jan 2002 13:34:06 -0800 (PST) Message-ID: <3C3B65EF.21DFD63D@cisco.com> Date: Tue, 08 Jan 2002 16:34:39 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Terry L Anderson CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] Re: [Sip-implementors] supporting just one codec at a time References: <3C3622EB.5040707@dynamicsoft.com> <3C36312F.F4E4CAAA@lucent.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 Terry L Anderson wrote: > Jonathan Rosenberg wrote: > > > Folks, > > > > I've been combing through the sip-implementors and sip lists, looking > > for open issues that need resolution, or comments that needed addressing > > in the specification. This is the source of much of my spamming on > > sip-implementors.... > > > > An issue that has arisen time and time and time again, is the need for > > an endpoint to indicate in its SDP that it can do any one of these three > > codecs, but can only do one at a time, that is, it doesn't support > > dynamically changing codecs on the fly. Since the question has been > > asked 1/2 dozen times on sip-implementors, and concerns both sip and > > mmusic, I have cross posted. If the thread takes off we'll trim it to a > > single list. > > > > The response I gave to people who asked about it, was that this was what > > simcap > > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt) > > was for, and to go read that. However, after a discussion with Flemming, > > it appears I misinterpreted that specification. It is merely a > > declaration of the codes that an endpoint can support. This information > > would be used in subsequent offer/answer exchanges, so that a UA can > > make an offer without having to guess whether it would or wouldn't be > > accepted. I was under the false impression that the point of simcap was > > to, in fact, solve this particular problem of one-codec-at-a-time for > > the initial exchange. > > > > So, we are faced with this gap of how to handle this problem. I see a > > few solutions: > > > > 1. Use a three-way handshake in SIP, using offer/counter-offer/answer. > > > > The offer would list ALL the codecs the UA can do, the counter-offer is > > the subset that the other UA can do, and the answer can reduce it > > further to just a few. > > > > This solution would require us to define this 3-way handshake somewhere; > > that is still being debated as an open issue. Bill has included this > > already in manyfolks, partly to solve this problem (or maybe entirely to > > solve this problem). > > > > 2. Define a backwards compatible usage of simcap to modify the > > offer-answer exchange. > > > > The offer would contain an m line with a single codec choice (in this > > particular case where it can do only one a time), but the offer would > > include simcap attributes indicating support for other codecs. The > > answerer could choose from amongst those codecs in formulating the > > answer. So, for example: > > > > Offer: > > > > m=audio 8778 RTP/AVP 0 76 > > a=rtpmap:76 telephone-event > > a=sqn:0 > > a=cdsc: 1 audio RTP/AVP 0 76 > > a=cdsc: 3 audio RTP/AVP 1 76 > > a=cdsc: 5 audio RTP/AVP 2 76 > > > > This offer means that the offerer is definitely using PCMU with someone > > that doesn't understand simcap, but is indicating they can also do > > codecs 1 and 2 (and each of them with rfc2833). The answerer could pick > > one of those alternate cdsc in the answer: > > > > m=audio 7554 RTP/AVP 1 76 > > a=rtpmap:76 telephone-event > > > > We would probably need to define an additional attribute in the SDP that > > indicates that this "simcap effects the m line selection" semantic is > > being followed. > > > > This approach may confused intermediaries that are assuming a subset of > > codecs in the answer. > > > > 3. Define a sort-of backwards compatible usage of simcap with offer/answer > > > > In this model, the offerer lists all codecs they can do in the offer. > > They include simcap declarations as well. As with normal offer/answer, > > the answerer has to pick a subset, but they use the simcap declarations > > to help them pick a subset which is an allowed capability. So, in the > > example above where the caller can do codecs 0,2,3,4 along with 76, but > > only ONE of 0,2,3,4 at a time, the O/A would look like this: > > > > OFFER: > > > > m=audio 8778 RTP/AVP 0 1 2 76 > > a=rtpmap:76 telephone-event > > a=sqn:0 > > a=cdsc: 1 audio RTP/AVP 0 76 > > a=cdsc: 3 audio RTP/AVP 1 76 > > a=cdsc: 5 audio RTP/AVP 2 76 > > > > ANSWER: > > m=audio 7554 RTP/AVP 1 76 > > a=rtpmap:76 telephone-event > > > > If, however, the UAS doesn't understand simcap, its possible that > > they'll return an SDP listing all four codecs, and possibly change them > > on the fly. That can be fixed, in general, by another re-invite which > > lists only a single codec. This will work, but might cause an RTT worth > > of media to be sent using a codec different from the one the UAC > > "loaded" into the DSP. > > > > 4. Declare that simcap is overkill for this one problem, and define a > > single attribute, a=pickone, which says to choose only one of the codecs > > in the m line. > > > > The "I can do one of N, but only one at a time" problem, IMHO, the only > > capability problem that anyone actually has in real usage. I will note > > that, in fact, this is the only capabilities question ever asked on > > sip-implementors. > > > > A single attribute would easily solve it. If you want to do rfc2833 > > along with any one of N other codecs, you could use fid along with this, > > to include an m line with the rfc2833, and then another m line with the > > N codecs and the a=pickone attribute. > > simcap is indeed overkill for this and I like new attribute as long as we relax > the requirement currently in offer-answer: > "Once the offerer has sent the offer, it MUST be prepared to receive > media described by that offer." > That would be a radical change from present-day SDP semantics. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 8 16:41: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 QAA11311 for ; Tue, 8 Jan 2002 16:41: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 QAA23842; Tue, 8 Jan 2002 16:41: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 QAA23774 for ; Tue, 8 Jan 2002 16:41:15 -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 QAA11281; Tue, 8 Jan 2002 16:41:13 -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 NAA13486; Tue, 8 Jan 2002 13:40:21 -0800 (PST) Message-ID: <3C3B6763.AF18D06B@cisco.com> Date: Tue, 08 Jan 2002 16:40:52 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jerry_yin@Mitel.COM CC: "'Jonathan Rosenberg'" , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] RE: [Sip-implementors] supporting just one codec at a time References: <000401c1957a$72fce690$0c4dc786@pc3002.mitel.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 Jerry Yin wrote: > Hi there, > > After I read the simcap > (http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.tx > t), I found that it is not backwards compatible with the SDP (RFC 2327). > Here's my comments. > > 1. the rtpmap's format in RFC 2327 is > > a=rtpmap: /[/ parameters>]. > While in simcap, it is : > a=rtpmap: telephone-event No. There's simply an example which has made an editorial mistake in omitting the . > > > Where is the "telephone-event" defined as an encoding name? RFC 2833. > If the UA is > implemented according to RFC 2327, how can it talk to the UAs implemented > according to the simcap? > Per RFC 2327, unknown attributes are simply ignored and simcap just defines a couple of extra attributes that can be ignored at will. > > 2. The "m=" header and "a=rtpmap" in RFC 2327 is good enough to describe the > media attributes already. I don't know why it is necessary to define a new > attributes of "a=cdsc" and "a=cpar". There are some redundant information > here, I think. > SDP has well-known shortcomings when it comes to capability description and negotiation. See e.g. http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdpng-req-01.txt for an analysis of these. > > 3. If we want to describe a subset of capabilities among all capabilities > the SDP claimed, we can simply introduce one new attribute to describe the > subset. > For example, > a=subset subset_codec_number : total_codec_number. > This way, even some UAs don't understand a = subset, they still can talk > with the one supports this attribute by at list one media streaming. > They can, but not with the semantics you intended. > > Here's an example: > v=0 > o=- 25678 753849 IN IP4 128.96.41.1 > s=- > c=IN IP4 128.96.41.1 > t=0 0 > m=audio 3456 RTP/AVP 96 97 98 > a=rtpmap:96 L8/8000 > a=rtpmap:97 L16/8000 > a=rtpmap:98 L16/11025/2 > a=subset 2:3 > m=video 3458 RTP/AVP 26 31 > a=rtpmap:26 JPEG/90000 > a=rtpmap:31 H261/90000 > a=subset 1:2 > > This packet means the sender can support two audio streams among three > different codecs {L8, L16, and L16-stereo} and one video stream of JPEG or > H261. This doesn't work if the receiver doesn't understand the "subset" attribute, hence it's not backwards compatible. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 9 00:03: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 AAA20421 for ; Wed, 9 Jan 2002 00:03: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 AAA06966; Wed, 9 Jan 2002 00:00: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 AAA06923 for ; Wed, 9 Jan 2002 00:00:05 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20371 for ; Wed, 9 Jan 2002 00:00:05 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g09505VZ010674; Wed, 9 Jan 2002 00:00:06 -0500 (EST) Message-ID: <3C3BCE35.4020600@dynamicsoft.com> Date: Tue, 08 Jan 2002 23:59:33 -0500 From: Jonathan Rosenberg 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: Flemming Andreasen CC: mmusic@ietf.org Subject: Re: [MMUSIC] resolving open issues in offer/answer References: <3C3B11DB.32C803E8@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > >>I think the best solution is to punt it ;). Seriously, though, this >> > may >>be a non-issue in many implementations, where there is no notion of >>unloading a codec. If an implementation needs to know when its safe to >>stop being prepared to receive with a codec, it can employ either the >>timer approach or the port change mechanism, both are local >>implementation choices that require no additional protocol semantics. >>So, we can describe both, discuss the issues, and leave it at that. >> >> > > Might as well describe the payload type change approach as well then > since it > seems to have the fewest problems as long as it's optional. Fair enough. I will be sure to document the limitations as well. Any other comments? This is the main open issue left in O/A; once there is agreement I can update and resubmit and we can then move into WGLC on it. -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 Jan 9 00: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 AAA20459 for ; Wed, 9 Jan 2002 00: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 AAA07441; Wed, 9 Jan 2002 00:04: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 AAA07406 for ; Wed, 9 Jan 2002 00:04:14 -0500 (EST) Received: from esuims01.esamsungumit.com ([203.122.29.230]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20433 for ; Wed, 9 Jan 2002 00:04:04 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Wed, 9 Jan 2002 10:38:33 +0530 Message-ID: <89CFEE6120A0224EA07781892EC0B48B43C3B6@esuims01.esamsungumit.com> Thread-Topic: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Thread-Index: AcGYjSzAoosU+htCRzmK8VJzNi8uHgAPk9Dw From: "ShavinderPal Singh" To: "Flemming Andreasen" , "Jonathan Rosenberg" , "Henning G. Schulzrinne" , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA07407 Subject: [MMUSIC] Post Dial Delay 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, Can any one tell me which rfc caters to the "definition" of "Post Dial delay" in SIP. and how to calculate it? If there is none, can anyone help me how do i verify if my Post Dial delay is less than 1.5 RTT Rgds s eSamsung UMIT, 15th floor, Signature Towers, South City-I, Gurgaon-122001, HR, IND. Ph.: 091-124-6383474 (e 250) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 9 00:14: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 AAA20520 for ; Wed, 9 Jan 2002 00:14: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 AAA07728; Wed, 9 Jan 2002 00:11: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 AAA07686 for ; Wed, 9 Jan 2002 00:11:32 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20503; Wed, 9 Jan 2002 00:11:31 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.83]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g095B3VZ010681; Wed, 9 Jan 2002 00:11:04 -0500 (EST) Message-ID: <3C3BD0C5.4030301@dynamicsoft.com> Date: Wed, 09 Jan 2002 00:10:29 -0500 From: Jonathan Rosenberg 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: Flemming Andreasen CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: > >>Offer: >> >>m=audio 8778 RTP/AVP 0 76 >>a=rtpmap:76 telephone-event >>a=sqn:0 >>a=cdsc: 1 audio RTP/AVP 0 76 >>a=cdsc: 3 audio RTP/AVP 1 76 >>a=cdsc: 5 audio RTP/AVP 2 76 >> >>This offer means that the offerer is definitely using PCMU with >> > someone > >>that doesn't understand simcap, but is indicating they can also do >>codecs 1 and 2 (and each of them with rfc2833). The answerer could >> > pick > >>one of those alternate cdsc in the answer: >> > > That's a slight overloading of the simcap semantics which doesn't define > any kind > of grouping of capabilities. Normal usage of simcap would only list a > given > capability once (per media stream at least). If you wanted to express > something > like the above, you would really want to define a new attribute that > could > describe allowable combinations of codecs, however that level of > expressiveness > was outside the scope of the simcap specification. I understand that now as well, once again, my misinterpretation of the simcap spec. Clearly I thought it was solving something that it is not. This leaves a larger hole than I thought. >>4. Declare that simcap is overkill for this one problem, and define a >>single attribute, a=pickone, which says to choose only one of the >>codecs in the m line. >>The "I can do one of N, but only one at a time" problem, IMHO, the >>only >>capability problem that anyone actually has in real usage. I will note >>that, in fact, this is the only capabilities question ever asked on >>sip-implementors. >> >>A single attribute would easily solve it. If you want to do rfc2833 >>along with any one of N other codecs, you could use fid along with >>this, to include an m line with the rfc2833, and then another m line with >>the N codecs and the a=pickone attribute. >> >> > > However that would require use of multiple ports which could lead to > multiple > resource reservations. Why? The rfc2833 could be on the same port, no? >Also, > - fid cannot be added by the answerer if the offer didn't include it due > to the > media stream matching rules Correct. That seems less of an issue, since if the offerer lists everything it can do, and the answerer is constrained, it can simply select one codec. > - if fid is included in the offer, but not supported by the answerer, > the handling > may not be all that graceful. Right. I am not wed to this specific mechanism. However, from my hopefully-now-correct understanding of simcap, it seems that it simply doesn't help at all with this issue of doing only one codec at a time. So, options 1 and 2 above are no-go. Another possibility is to add an extension to simcap which allows you to convey this one particular constraint. -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 Jan 9 00:17: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 AAA20539 for ; Wed, 9 Jan 2002 00:17: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 AAA07868; Wed, 9 Jan 2002 00:14: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 AAA07833 for ; Wed, 9 Jan 2002 00:14:29 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20516 for ; Wed, 9 Jan 2002 00:14:28 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id AAA04356; Wed, 9 Jan 2002 00:13:55 -0500 (EST) Received: from bart.cs.columbia.edu (localhost [127.0.0.1]) by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id g095Dspg004818; Wed, 9 Jan 2002 00:13:55 -0500 (EST) Received: from localhost (sankaran@localhost) by bart.cs.columbia.edu (8.12.1/8.12.1/Submit) with ESMTP id g095DruJ004815; Wed, 9 Jan 2002 00:13:54 -0500 (EST) Date: Wed, 9 Jan 2002 00:13:53 -0500 (EST) From: Sankaran Narayanan To: ShavinderPal Singh cc: , In-Reply-To: <89CFEE6120A0224EA07781892EC0B48B43C3B6@esuims01.esamsungumit.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] Re: [Sip-implementors] Post Dial Delay 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 suppose one reference is http://www.cs.columbia.edu/~hgs/papers/Eyer0004_Predicting.pdf ------------------------------------------------------------------- Sankaran Narayanan http://www.cs.columbia.edu/~sankaran On Wed, 9 Jan 2002, ShavinderPal Singh wrote: > Hi, > > Can any one tell me which rfc caters to the "definition" of "Post Dial > delay" in SIP. and how to calculate it? > If there is none, can anyone help me how do i verify if my Post Dial > delay is less than 1.5 RTT > > > Rgds > s > > > eSamsung UMIT, 15th floor, Signature Towers, > South City-I, Gurgaon-122001, HR, IND. > Ph.: 091-124-6383474 (e 250) > _______________________________________________ > 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 Wed Jan 9 07:13: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 HAA02937 for ; Wed, 9 Jan 2002 07:13: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 HAA28970; Wed, 9 Jan 2002 07:13: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 HAA28930 for ; Wed, 9 Jan 2002 07:13:11 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02931 for ; Wed, 9 Jan 2002 07:13:08 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g09CD9J20469 for ; Wed, 9 Jan 2002 13:13:09 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Jan 09 13:12:37 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jan 2002 13:12:21 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Brian Weis'" Cc: msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29?= Date: Wed, 9 Jan 2002 13:12:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: MIKEY mapping of keys to steams -- possible vulnerability 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 Brian, and thanks for the comments. They are most valid. I see three ways of solving it (without making a too complex solution). 1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is mainly what we have done so far. 2) Begin using the extra keymgmt-auth attribute that we are introducing in SDP. We introduced an extra SDP attribute in order to be able to authenticate part of the SDP description if necessary (this is however still an undocumented feature in the current MIKEY draft). Your comments may give us a reason to pursue with that attribute and use it to "tie" the media description to the MIKEY data (in case it is not already provided by SIP/RTSP/SDP). A small example of how it could work: | a=keymgmt-prot:MIKEY | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... | a=keymgmt-auth:q9wuIs5du2ISD7 MCS < CS 1 < m=audio 49000 RTP/SAVP 98 | a=rtpmap:98 AMR/8000 | CS 2 < m=video 2232 RTP/SAVP 31 where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP server (or another intermediate node) may need to change things like IP addresses and ports in the SDP, and thereby the authentication will fail (if it is computed over these fields). 3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as input to any id), i.e. set q = hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC in MIKEY include q. The hash could in this case be as just another payload in MIKEY. It would of course be authenticated and the result would be equal to that in 2). This will however have the same NAT problems as in 2). This approach will have the disadvantage that we might need to build in too much knowledge about SDP in MIKEY. Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security protocols for 1) will solve). Best Regards, Fredrik > -----Original Message----- > From: Brian Weis [mailto:bew@cisco.com] > Sent: den 7 januari 2002 21:04 > To: fredrik.lindholm@era.ericsson.se; > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > mats.naslund@era.ericsson.se > Cc: msec@securemulticast.org > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > I have a question on how MIKEY accurately maintains a mapping > of keys to > audio/video streams in an SDP specification. I've given my > understanding > of how this happens so you can check my assumptions, and then > I suggest > a possibly vulnerability. > > MIKEY specifies a new concept of "crypto session id" which it uses to > label media streams which are later defined in an SDP description The > crypto session id is a logical identity where the first media session > ("m=") statement is associated with the first crypto session id, the > second media session statement is associated with the second crypto > session id, etc. (This seems clear from section 6. of MIKEY.) > > The format of the crypto session id is specified in section A.1. The > concept of the MCS ID is defined to be an 80-bit random number which > doesn't describe the media session at all, and I can't tell how the CS > IDs are defined but I see nothing which is mappable to the > actual media > streams. > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > detected within the key management data. > > But MIKEY cannot detect if the "m=" statements in the SDP description > have been replaced or otherwise modified. To illustrate my point, here > is the example in the MIKEY document: > > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > > Suppose this was modified by a man-in-the-middle and the SDP > was changed > to this: > > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > | CS 2 < m=audio 49170 RTP/SAVP 31 > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > description, but applied to the wrong media streams. > > This could be considered a DoS attack. In the case of a > multicast group, > it's a more serious attack: if a dishonest group member (holding the > encryption keys) changes the SDP before other group members see it, he > can source different media streams which match the new SDP definition. > These will be authenticated in MIKEY and accepted as the > valid streams, > when in fact they are not what the person who sent the MIKEY > definition > intended. > > I realize that MIKEY did not intend to protect the "m=" statements in > any way. But it seems to me that the implicit references to > the rest of > the SDP definition affects the validity of MIKEY. > > One way to solve this might be to include something in the CS > ID so that > the media can be verified (e.g., a hash of the "m=" > statement). But that > doesn't handle all of the dependencies on the SDP statements. MIKEY is > also dependent on the "c=" statement defining the actual multicast > address. > > Another solution would be to require that MIKEY be used in conjunction > with a separate authentication system which authenticates the > entire SDP > definition. (For example, SIP defines some authentication using PGP > although I've heard comments that on one actually uses it.) This seems > to me to be the safest approach, but it is too bad that MIKEY would be > dependent on other systems. > > I'm anxious to hear your comments. > > Thanks, > Brian > -- > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 9 09:21: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 JAA04193 for ; Wed, 9 Jan 2002 09:21: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 JAA02750; Wed, 9 Jan 2002 09:21: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 JAA02708 for ; Wed, 9 Jan 2002 09:21:27 -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 JAA04174; Wed, 9 Jan 2002 09:21:23 -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 GAA00975; Wed, 9 Jan 2002 06:19:38 -0800 (PST) Message-ID: <3C3C5199.4444C8F2@cisco.com> Date: Wed, 09 Jan 2002 09:20:09 -0500 From: Flemming Andreasen Organization: Cisco Systems X-Mailer: Mozilla 4.78 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@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: > > >>4. Declare that simcap is overkill for this one problem, and define a > >>single attribute, a=pickone, which says to choose only one of the > >>codecs in the m line. > >>The "I can do one of N, but only one at a time" problem, IMHO, the > >>only > >>capability problem that anyone actually has in real usage. I will note > >>that, in fact, this is the only capabilities question ever asked on > >>sip-implementors. > >> > >>A single attribute would easily solve it. If you want to do rfc2833 > >>along with any one of N other codecs, you could use fid along with > >>this, to include an m line with the rfc2833, and then another m line with > >>the N codecs and the a=pickone attribute. > >> > >> > > > > However that would require use of multiple ports which could lead to > > multiple > > resource reservations. > > Why? The rfc2833 could be on the same port, no? > No. The fid-draft does not allow the different "m=" lines to have the same destination (IP address and port) > > > - if fid is included in the offer, but not supported by the answerer, > > the handling > > may not be all that graceful. > > Right. > > I am not wed to this specific mechanism. However, from my > hopefully-now-correct understanding of simcap, it seems that it simply > doesn't help at all with this issue of doing only one codec at a time. It doesn't solve this particular problem by itself, however it provides a mechanism that can be used to help solve it while remaining backwards compatible. In its present form, you can send an INVITE/offer listing only one codec in the "m=" line, and then include all codecs supported in the capabilites. The answerer can accept this, and then do another re-INVITE picking one or more codecs from the capabilites if you wants to use a different one. > > So, options 1 and 2 above are no-go. > > Another possibility is to add an extension to simcap which allows you to > convey this one particular constraint. > Right. In that case you would probably also define an offer/answer extension that would the answerer to pick codecs from the capabilities, and not just the "m=" line. -- Flemming -- Flemming Andreasen Cisco Systems _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 9 12:31:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07800 for ; Wed, 9 Jan 2002 12:31: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 MAA12740; Wed, 9 Jan 2002 12:31: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 MAA12662 for ; Wed, 9 Jan 2002 12:31:01 -0500 (EST) Received: from sm14.texas.rr.com (sm14.texas.rr.com [24.93.35.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07785; Wed, 9 Jan 2002 12:30:56 -0500 (EST) Received: from plong1 (bu24242141-164.austin.rr.com [24.242.141.164]) by sm14.texas.rr.com (8.12.0.Beta16/8.12.0.Beta16) with SMTP id g09HWWu3016872; Wed, 9 Jan 2002 11:32:32 -0600 From: "Paul Long" To: , , Subject: RE: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Date: Wed, 9 Jan 2002 11:26:49 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <3C3BD0C5.4030301@dynamicsoft.com> Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Jonathan, Regarding your (rhetorical?) question, "The rfc2833 could be on the same port, no?", there is no SHALL in the statement, but it sounds like RFC 2833 packets are intended to always be on the same port as the audio stream: 3.1/RFC2833: "DTMF digits and named telephone events are carried as part of the audio stream..." Paul Long ipDialog, Inc. -----Original Message----- From: sip-implementors-admin@cs.columbia.edu [mailto:sip-implementors-admin@cs.columbia.edu]On Behalf Of Jonathan Rosenberg Sent: Tuesday, January 08, 2002 11:10 PM To: Flemming Andreasen Cc: sip@ietf.org; sip-implementors@cs.columbia.edu; mmusic@ietf.org Subject: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time Flemming Andreasen wrote: > >>Offer: >> >>m=audio 8778 RTP/AVP 0 76 >>a=rtpmap:76 telephone-event >>a=sqn:0 >>a=cdsc: 1 audio RTP/AVP 0 76 >>a=cdsc: 3 audio RTP/AVP 1 76 >>a=cdsc: 5 audio RTP/AVP 2 76 >> >>This offer means that the offerer is definitely using PCMU with >> > someone > >>that doesn't understand simcap, but is indicating they can also do >>codecs 1 and 2 (and each of them with rfc2833). The answerer could >> > pick > >>one of those alternate cdsc in the answer: >> > > That's a slight overloading of the simcap semantics which doesn't define > any kind > of grouping of capabilities. Normal usage of simcap would only list a > given > capability once (per media stream at least). If you wanted to express > something > like the above, you would really want to define a new attribute that > could > describe allowable combinations of codecs, however that level of > expressiveness > was outside the scope of the simcap specification. I understand that now as well, once again, my misinterpretation of the simcap spec. Clearly I thought it was solving something that it is not. This leaves a larger hole than I thought. >>4. Declare that simcap is overkill for this one problem, and define a >>single attribute, a=pickone, which says to choose only one of the >>codecs in the m line. >>The "I can do one of N, but only one at a time" problem, IMHO, the >>only >>capability problem that anyone actually has in real usage. I will note >>that, in fact, this is the only capabilities question ever asked on >>sip-implementors. >> >>A single attribute would easily solve it. If you want to do rfc2833 >>along with any one of N other codecs, you could use fid along with >>this, to include an m line with the rfc2833, and then another m line with >>the N codecs and the a=pickone attribute. >> >> > > However that would require use of multiple ports which could lead to > multiple > resource reservations. Why? The rfc2833 could be on the same port, no? >Also, > - fid cannot be added by the answerer if the offer didn't include it due > to the > media stream matching rules Correct. That seems less of an issue, since if the offerer lists everything it can do, and the answerer is constrained, it can simply select one codec. > - if fid is included in the offer, but not supported by the answerer, > the handling > may not be all that graceful. Right. I am not wed to this specific mechanism. However, from my hopefully-now-correct understanding of simcap, it seems that it simply doesn't help at all with this issue of doing only one codec at a time. So, options 1 and 2 above are no-go. Another possibility is to add an extension to simcap which allows you to convey this one particular constraint. -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 Jan 9 12:55:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08239 for ; Wed, 9 Jan 2002 12:55: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 MAA13361; Wed, 9 Jan 2002 12:55: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 MAA13321 for ; Wed, 9 Jan 2002 12:55:31 -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 MAA08234; Wed, 9 Jan 2002 12:55:28 -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 g09Ht9A21035; Wed, 9 Jan 2002 12:55:10 -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 AAA26187 (AUTH pkyzivat); Wed, 9 Jan 2002 12:57:37 -0500 (EST) Message-ID: <3C3C82D9.32BA8081@cisco.com> Date: Wed, 09 Jan 2002 12:50:17 -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: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@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: > > It doesn't solve this particular problem by itself, however it provides a > mechanism that can be used to help solve it while remaining backwards > compatible. In its present form, you can send an INVITE/offer listing only one > codec in the "m=" line, and then include all codecs supported in the > capabilites. The answerer can accept this, and then do another re-INVITE > picking one or more codecs from the capabilites if you wants to use a different > one. How about a variant of this - an Invite where the offer includes *no* m= lines, but uses simcap to describe what is available. The recipient would be expected to accept the invite with no media, perhaps also returning capabilities. Then one side or the other need to send a reinvite to establish media. This provides the extra round trip to do negotiation. But it requires significant support from all parties. An alternative that I was going to mention is to precede the INVITE with an OPTIONS request to discover what the other side is capable of. But it suffers from a serious problem - it doesn't establish a dialog, so there is no guarantee that the subsequent INVITE will go to the same place. Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 9 21:46: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 VAA26568 for ; Wed, 9 Jan 2002 21:46: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 VAA29555; Wed, 9 Jan 2002 21:46: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 VAA29520 for ; Wed, 9 Jan 2002 21:46:07 -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 VAA26560 for ; Wed, 9 Jan 2002 21:46:02 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Wed, 09 Jan 2002 18:45:27 -0800 Received: from GOOMOON ([172.23.106.86]) by prognet.com (8.9.2/8.9.0) with ESMTP id SAA17680 for ; Wed, 9 Jan 2002 18:45:28 -0800 (PST) Date: Wed, 9 Jan 2002 18:44:12 -0800 (Pacific Standard Time) From: Rob Lanphier To: mmusic@ietf.org Message-ID: X-X-Sender: robla@goobox.prognet.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP ad hoc 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 for the RTSP ad hoc telecon previously announced on this list. If you reply to this, please change the subject of your email to reflect the issue you are talking about (preferably referring to bug number). The minutes are available in text form below and in HTML at the following address: http://rtsp.org/2002/telecon/jan09.html Next telecon is in two weeks, where we plan to close out these issues, so let us know what you think on these issues. If you missed this telecon, but want to join future telecons, read on. Thanks Rob Rtsp Tc Minutes09 Jan2002 _________________________________________________________________ 1. [1]Attendees 2. [2]General Process 3. [3]Action Items/New Issues 4. [4]Resolutions 5. [5]Issue Discussion 1. [6]#448521 URLs in Rtp-Info need to be quoted 2. [7]#449074 - RTP Seqnum offset in Pause Play response 3. [8]#461083 - Body w/o Content-Length clarification 4. [9]#447404 - Errors in table in chapter 12 5. [10]#477407 - Transport BNF, ; and unclearities 6. [11]new issue, to be logged 7. [12]477413 Transport BNF: mode 8. [13]#477416 BNF error section 3.6 NPT Attendees * Magnus Westerlund * Joerg Ott * Jonathan Sergent * Rob Lanphier * David Walker * Milko Boic * Anders Klemets * Henning Schulzrinne * Tom Marshall General Process The process we agreed on moving forward is as follows: * Telecon every two weeks, Wednesday at 9AM PST (17:00 GMT) for 90 minutes, subject to consensus among ad hoc group members. Though we anticipate this will be the regular time, we may move this on a per telecon basis to schedules or timezone differences (e.g. if someone in Japan wants to participate without having to stay up to 2:30 am) * Agenda with issues to discuss gets sent out to the working group on Friday prior to the telecon * Deadline is set for one or two weeks out, depending on issue - Note: Milko proposes that we use the telecons as a deadline for issues -- that also gives us the opportunity to "close" issues from previous week on the telecon. Any objections? - Also note: This ad hoc group doesn't have official status, so final place to close issues is always on the mailing list. The mailing list deadline would just happen to correspond to the telecon. For practical concerns, telecon attendance is limited to those who RSVP to me no later than 5pm PST Monday (1:00 GMT Tuesday), and may also be limited by other criteria if the need arises. However, open participation via IRC is always welcome ([14]irc://irc.openprojects.net/#rtspspec). Action Items/New Issues * NEW ISSUE: Should timestamps increase while stream is paused? * ACTION ITEM: Rob: ping Dave Singer on #461083 and encourage future participation * NEW ISSUE: should interleave parameter require value? * ACTION ITEM: Tom: request new bug "clarify requirement that interleave requires value" Resolutions * [15]448521 URLs in Rtp-Info need to be quoted + RESOLVED: Go with proposed resolution, with semicolon and comma as "dangerous characters". * [16]449074 - RTP Seqnum offset in Pause Play response + RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement. * [17]461083 - Body w/o Content-Length clarification + RESOLVED: require Content-length always, and eliminate implicit body-length via connection: close. * [18]447404 - Errors in table in chapter 12 + RESOLVED: evaluate SIP table format and move to that unless someone objects (and justifies) * [19]477407 - Transport BNF, ; and unclearities + RESOLVED: BNF will require semicolon, no mandated ordering, and example will be added. Example should include multiple entries of same type. However, will prohibit duplicated fields within a type entry. * [20]477413 - Transport BNF: mode + RESOLVED: Rework BNF, fixing multiple problems not limited to allow outside quotes, but not inside quotes. Quotes are optional * [21]477416 - BNF error section 3.6 NPT + RESOLVED: require npt=, but have backwards-compatibility note. Need to check BNF to make sure that not having npt= can work, and make sure everyone is aware that may be confusion may result Issue Discussion Here's the minutes from the discussion #448521 URLs in Rtp-Info need to be quoted [22]448521 Jonathan: proposed solution is fine Colin: why not URL encoding? Henning: Doesn't work. Lose distinction between truly escaped semicolons and escaped for this purpose Anders: which characters? ; , = Henning: equals sign ok Jonothan: requiring quotes on = is problematic Henning: semicolon and comma RESOLVED: semicolon and comma are "dangerous characters" Milko: quoting the whole URL? Henning: yes deadline? Henning: one or two weeks, depending on issue #449074 - RTP Seqnum offset in Pause Play response [23]449074 Jonathan: We do this anyway. RTP requires it Henning: agreed Milko: If indeed the server needs a newly generated number, the RTP-info is there. Henning: violates RFC 1889 Rob: Real doesn't do this right. Does Darwin? Henning: Doesn't matter. RFC 1889 is pretty clear here. RTSP spec should reference RFC 1889 to clarify Jonathan: Need to clarify that SSRC changing midstream is a bad idea Colin: timestamp changing could be a problem Henning: implementation robustness issue Magnus: need to look at Appendix B (RTP usage) because it implies that timestamps continue increasing NEW ISSUE: timestamps monotonically increasing Milko: resolution should be related on new issue and current issue Henning: timestamp corresponds to display time RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement #461083 - Body w/o Content-Length clarification [24]461083 Sean: like requiring content length Henning: make sure consistency with SIP. Specifying is preferred. Joerg: any examples of long implied length? Jonathan: Darwin does this for errors. Surprised that this may be issue Tom: Darwin doubles as HTTP server Rob: RTSP differs in this regard because no CGI issues RESOLVED: require Content-length always. (two week issue) ACTION ITEM: Rob: ping Dave Singer on this issue and encourage future participation Henning: Checked spec, and resolution is consistent with SIP RESOLVED: eliminate implicit body-length via connection: close #447404 - Errors in table in chapter 12 [25]447404 Magnus: need to add columns to clarify which headers are needed, required, etc. Henning: latest SIP draft has equivalent table. Should keep same format. RESOLVED: evaluate SIP table format and move to that unless someone objects (and justifies) #477407 - Transport BNF, ; and unclearities [26]477407 Jonathan: ours requires ; before unicast and multicast Henning: once we insert semicolon, parameter ordering doesn't matter Jonathan: based on current way this is stated, you can have semicolon Jonathan: BNF is broken Sean: Server client order don't matter in implementations I'm aware of Colin: Example would be good RESOLVED: BNF will require semicolon, no mandated ordering, and example will be added Colin: should multiple entries of same type be allowed? Henning: any reason to prohibit? Jonathan: prohibiting doesn't make it more useful Henning: no duplication *within* an item Henning: we should set precedent for new params (Henning drops off) new issue, to be logged Tom: RealPlayer uses interleaved without interleaved parameter Anders: we discussed at interop meeting. Client needs to specify some channel numbers, but server would treat those as recommendation, but server is free to choose new number. Jonathan: is same true on port numbers? Rob: unicast: client is the authority multicast: server is the authority NEW ISSUE: should interleave parameter require value? (Suggested resolution): parameter is required, and treated as a suggestion when it doesn't make sense as authoritative response. ACTION ITEM: Tom: request new bug "clarify requirement that interleave requires value" 477413 Transport BNF: mode [27]477413 Jonathan: issue is about two sets of quotes Magnus: that's right RESOLVED: fix BNF to allow outside quotes, but not inside quotes Jonathan: BNF is confused on issue of comma placement as well. RESOLVED: fix BNF Sean: will proposed fix allow mode=PLAY (no quotes) Magnus: doesn't that change status quo? Jonathan: No Jonathan: Lots of implementations don't do this Joerg: whatever happens, we should have BNF that has optional quotes RESOLVED: quotes are optional #477416 BNF error section 3.6 NPT [28]477416 Jonathan: seems like examples are more in line with current use Sean: this has caused us grief because some treat as optional RESOLVED: require npt=, but have backwards-compatibility note Joerg: need to check BNF to make sure that not having npt= can work Joerg: make sure everyone is aware that may be confusion may result Joerg: BNF audit is necessary to ensure that implementations can even deal with no npt= possibility References 1. http://rtsp.org/2002/telecon/jan09.html#line11 2. http://rtsp.org/2002/telecon/jan09.html#line23 3. http://rtsp.org/2002/telecon/jan09.html#line38 4. http://rtsp.org/2002/telecon/jan09.html#line45 5. http://rtsp.org/2002/telecon/jan09.html#line62 6. http://rtsp.org/2002/telecon/jan09.html#line66 7. http://rtsp.org/2002/telecon/jan09.html#line94 8. http://rtsp.org/2002/telecon/jan09.html#line128 9. http://rtsp.org/2002/telecon/jan09.html#line154 10. http://rtsp.org/2002/telecon/jan09.html#line164 11. http://rtsp.org/2002/telecon/jan09.html#line194 12. http://rtsp.org/2002/telecon/jan09.html#line210 13. http://rtsp.org/2002/telecon/jan09.html#line236 14. irc://irc.openprojects.net/#rtspspec 15. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=448521 16. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=449074 17. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=461083 18. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=447404 19. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477407 20. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477413 21. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477416 22. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=448521 23. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=449074 24. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=461083 25. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=447404 26. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477407 27. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477413 28. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477416 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 11 17:37:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02253 for ; Fri, 11 Jan 2002 17:37: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 RAA19691; Fri, 11 Jan 2002 17:36:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19658 for ; Fri, 11 Jan 2002 17:36:52 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02243 for ; Fri, 11 Jan 2002 17:36:49 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g0BMa4414825; Fri, 11 Jan 2002 14:36:04 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn1-718.cisco.com [10.21.98.206]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAQ18951; Fri, 11 Jan 2002 14:35:30 -0800 (PST) Message-Id: <4.3.2.7.2.20020111141119.0460bdc8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 11 Jan 2002 14:33:56 -0800 To: "Fredrik Lindholm (ERA)" From: Mark Baugher Cc: "'Brian Weis'" , msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, Mats =?iso-8859-1?Q?N=E4slund?= (ERA) In-Reply-To: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MMUSIC] Re: [MSEC] RE: MIKEY mapping of keys to steams -- possible vulnerability 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 Fredrik Doesn't this problem conflict with one of your stated design goals of Section 2.2: Independence of the security of the underlying transport? All three of these solutions seem to me to violate that design goal. It seems to me that you need to remove the dependency that you have on the integrity of SDP messages in order to preserve your goals. Mark At 01:12 PM 1/9/2002 +0100, Fredrik Lindholm (ERA) wrote: >Hi Brian, > >and thanks for the comments. They are most valid. > >I see three ways of solving it (without making a too complex solution). > >1) Assume that SIP, RTSP, or SDP can transport the description in a secure >and reliable way to its destination (e.g. we have the SIP security group >that are working with this problem). This is mainly what we have done so far. > >2) Begin using the extra keymgmt-auth attribute that we are introducing in >SDP. We introduced an extra SDP attribute in order to be able to >authenticate part of the SDP description if necessary (this is however >still an undocumented feature in the current MIKEY draft). Your comments >may give us a reason to pursue with that attribute and use it to "tie" the >media description to the MIKEY data (in case it is not already provided by >SIP/RTSP/SDP). > >A small example of how it could work: > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > | a=keymgmt-auth:q9wuIs5du2ISD7 > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > >where the authentication field is computed over a well-defined subset of >SDP (this could of course include the c= line). There is mainly one >problem with this. If the user is behind a NAT, the SIP server (or another >intermediate node) may need to change things like IP addresses and ports >in the SDP, and thereby the authentication will fail (if it is computed >over these fields). > >3) An idea, similar to the one you proposed. Instead of including the hash >of some specific field, a hash over a well-defined subset or the entire >SDP description could be provided (but not as input to any id), i.e. set q >= hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC >in MIKEY include q. The hash could in this case be as just another payload >in MIKEY. It would of course be authenticated and the result would be >equal to that in 2). This will however have the same NAT problems as in >2). This approach will have the disadvantage that we might need to build >in too much knowledge about SDP in MIKEY. > >Exactly what to aim at is something that needs to be discussed. In the >future, we will probably be able to rely on 1) (and we need doing so >unless we want to solve the same issues the security protocols for 1) will >solve). > >Best Regards, >Fredrik > > > > -----Original Message----- > > From: Brian Weis [mailto:bew@cisco.com] > > Sent: den 7 januari 2002 21:04 > > To: fredrik.lindholm@era.ericsson.se; > > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > > mats.naslund@era.ericsson.se > > Cc: msec@securemulticast.org > > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > > > > I have a question on how MIKEY accurately maintains a mapping > > of keys to > > audio/video streams in an SDP specification. I've given my > > understanding > > of how this happens so you can check my assumptions, and then > > I suggest > > a possibly vulnerability. > > > > MIKEY specifies a new concept of "crypto session id" which it uses to > > label media streams which are later defined in an SDP description The > > crypto session id is a logical identity where the first media session > > ("m=") statement is associated with the first crypto session id, the > > second media session statement is associated with the second crypto > > session id, etc. (This seems clear from section 6. of MIKEY.) > > > > The format of the crypto session id is specified in section A.1. The > > concept of the MCS ID is defined to be an 80-bit random number which > > doesn't describe the media session at all, and I can't tell how the CS > > IDs are defined but I see nothing which is mappable to the > > actual media > > streams. > > > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > > detected within the key management data. > > > > But MIKEY cannot detect if the "m=" statements in the SDP description > > have been replaced or otherwise modified. To illustrate my point, here > > is the example in the MIKEY document: > > > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > > | a=rtpmap:98 AMR/8000 > > | CS 2 < m=video 2232 RTP/SAVP 31 > > > > Suppose this was modified by a man-in-the-middle and the SDP > > was changed > > to this: > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > > | CS 2 < m=audio 49170 RTP/SAVP 31 > > > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > > description, but applied to the wrong media streams. > > > > This could be considered a DoS attack. In the case of a > > multicast group, > > it's a more serious attack: if a dishonest group member (holding the > > encryption keys) changes the SDP before other group members see it, he > > can source different media streams which match the new SDP definition. > > These will be authenticated in MIKEY and accepted as the > > valid streams, > > when in fact they are not what the person who sent the MIKEY > > definition > > intended. > > > > I realize that MIKEY did not intend to protect the "m=" statements in > > any way. But it seems to me that the implicit references to > > the rest of > > the SDP definition affects the validity of MIKEY. > > > > One way to solve this might be to include something in the CS > > ID so that > > the media can be verified (e.g., a hash of the "m=" > > statement). But that > > doesn't handle all of the dependencies on the SDP statements. MIKEY is > > also dependent on the "c=" statement defining the actual multicast > > address. > > > > Another solution would be to require that MIKEY be used in conjunction > > with a separate authentication system which authenticates the > > entire SDP > > definition. (For example, SIP defines some authentication using PGP > > although I've heard comments that on one actually uses it.) This seems > > to me to be the safest approach, but it is too bad that MIKEY would be > > dependent on other systems. > > > > I'm anxious to hear your comments. > > > > Thanks, > > Brian > > -- > > Brian Weis > > Strategic Cryptographic Development, ITD, Cisco Systems > > Telephone: +1 408 526 4796 > > Email: bew@cisco.com > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 11 20:54:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04355 for ; Fri, 11 Jan 2002 20:54:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA24065; Fri, 11 Jan 2002 20:54: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 UAA24032 for ; Fri, 11 Jan 2002 20:54:31 -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 UAA04350 for ; Fri, 11 Jan 2002 20:54:28 -0500 (EST) Received: from cisco.com (rajitha-w2k3.cisco.com [128.107.163.156]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id RAA02843; Fri, 11 Jan 2002 17:53:26 -0800 (PST) Message-ID: <3C3F9716.6E1CDA89@cisco.com> Date: Fri, 11 Jan 2002 17:53:26 -0800 From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Fredrik Lindholm (ERA)" CC: msec@securemulticast.org, "'mmusic@ietf.org'" , " Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, "Mats =?iso-8859-1?Q?N=E4slund?= (ERA)" Subject: Re: [MMUSIC] RE: MIKEY mapping of keys to steams -- possible vulnerability References: <0DAEDF148988D411BB980008C7E65D2E04FE3F86@esealnt416> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Content-Transfer-Encoding: 7bit Hi Fredrik, Thanks for your response. I've got some more comments inline. "Fredrik Lindholm (ERA)" wrote: > > Hi Brian, > > and thanks for the comments. They are most valid. > > I see three ways of solving it (without making a too complex solution). > > 1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is mainly what we have done so far. Right, that would be work in terms of securing a system. But as Mark pointed out, in terms of the protocol definition this approach means that your statement in Section 2.2 of MIKEY may not be quite true * Independent of the security of the underlying transport. if you think of the session establishment protocol being part of the term "underlying transport". > 2) Begin using the extra keymgmt-auth attribute that we are introducing in SDP. We introduced an extra SDP attribute in order to be able to authenticate part of the SDP description if necessary (this is however still an undocumented feature in the current MIKEY draft). Your comments may give us a reason to pursue with that attribute and use it to "tie" the media description to the MIKEY data (in case it is not already provided by SIP/RTSP/SDP). > > A small example of how it could work: > | a=keymgmt-prot:MIKEY > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > | a=keymgmt-auth:q9wuIs5du2ISD7 > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > | a=rtpmap:98 AMR/8000 > | CS 2 < m=video 2232 RTP/SAVP 31 > > where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP server (or another intermediate node) may need to change things like IP addresses and ports in the SDP, and thereby the authentication will fail (if it is computed over these fields). Thanks for pointing out the proposed keymgmt-auth attribute It does begin to solve the authentication problem, but I don't think specifying it will be so easy. The NAT problem is interesting. I didn't know that NAT boxes were SDP (or SIP and RTSP) aware. But if the c= line isn't in the authenticated subset of the SDP definition then it's questionable whether validating the integrity of the rest of the SDP definition is worthwhile -- an attacker can still change the media streams to which the MIKEY keys will be applied to (same ports, different machine). > 3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as input to any id), i.e. set q = hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC in MIKEY include q. The hash could in this case be as just another payload in MIKEY. It would of course be authenticated and the result would be equal to that in 2). This will however have the same NAT problems as in 2). This approach will have the disadvantage that we might need to build in too much knowledge about SDP in MIKEY. Yes, I think that no matter what you choose to hash you'll either have too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in SDP. In the example above, who does the hash() on the local system? If the SDP code does it then it has to know about creating a MIKEY-specific hash. If the MIKEY code does it, then it has to be given access to the entire SDP description and it has to know how to parse it. This applies to both solutions 2) and 3). You can think of it as a protocol layering violation problem. I suggest that you put some more thought into the a=keymgmt-auth attribute defined in draft-ietf-mmusic-kmgmt-ext-00.txt draft. If you can't come up with a way of addressing the layering problem you should probably remove it from that draft and mention the integrity issue there too. > Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security protocols for 1) will solve). Yes, 1) is your best bet for now. But you should add some text to the MIKEY draft pointing out the problem and describe the dependency. I have put some thought into a generic SDP authentication attribute (which would not be part of any particular key management system, and could be used by itself to authenticate any SDP description.) If that's seen as appropriate I'll submit it mmusic. Thanks, Brian > Best Regards, > Fredrik > > > -----Original Message----- > > From: Brian Weis [mailto:bew@cisco.com] > > Sent: den 7 januari 2002 21:04 > > To: fredrik.lindholm@era.ericsson.se; > > elisabetta.carrara@era.ericsson.se; jari.arkko@ericsson.com; > > mats.naslund@era.ericsson.se > > Cc: msec@securemulticast.org > > Subject: MIKEY mapping of keys to steams -- possible vulnerability > > > > > > I have a question on how MIKEY accurately maintains a mapping > > of keys to > > audio/video streams in an SDP specification. I've given my > > understanding > > of how this happens so you can check my assumptions, and then > > I suggest > > a possibly vulnerability. > > > > MIKEY specifies a new concept of "crypto session id" which it uses to > > label media streams which are later defined in an SDP description The > > crypto session id is a logical identity where the first media session > > ("m=") statement is associated with the first crypto session id, the > > second media session statement is associated with the second crypto > > session id, etc. (This seems clear from section 6. of MIKEY.) > > > > The format of the crypto session id is specified in section A.1. The > > concept of the MCS ID is defined to be an 80-bit random number which > > doesn't describe the media session at all, and I can't tell how the CS > > IDs are defined but I see nothing which is mappable to the > > actual media > > streams. > > > > MIKEY protects the "a=keymgmt-data" data such that tampering can be > > detected within the key management data. > > > > But MIKEY cannot detect if the "m=" statements in the SDP description > > have been replaced or otherwise modified. To illustrate my point, here > > is the example in the MIKEY document: > > > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=audio 49000 RTP/SAVP 98 > > | a=rtpmap:98 AMR/8000 > > | CS 2 < m=video 2232 RTP/SAVP 31 > > > > Suppose this was modified by a man-in-the-middle and the SDP > > was changed > > to this: > > > > | a=keymgmt-prot:MIKEY > > | a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD... > > MCS < CS 1 < m=video 53172 RTP/SAVP 98 > > | CS 2 < m=audio 49170 RTP/SAVP 31 > > > > The keys in keymgmt-data will be correctly transmitted in the MIKEY > > description, but applied to the wrong media streams. > > > > This could be considered a DoS attack. In the case of a > > multicast group, > > it's a more serious attack: if a dishonest group member (holding the > > encryption keys) changes the SDP before other group members see it, he > > can source different media streams which match the new SDP definition. > > These will be authenticated in MIKEY and accepted as the > > valid streams, > > when in fact they are not what the person who sent the MIKEY > > definition > > intended. > > > > I realize that MIKEY did not intend to protect the "m=" statements in > > any way. But it seems to me that the implicit references to > > the rest of > > the SDP definition affects the validity of MIKEY. > > > > One way to solve this might be to include something in the CS > > ID so that > > the media can be verified (e.g., a hash of the "m=" > > statement). But that > > doesn't handle all of the dependencies on the SDP statements. MIKEY is > > also dependent on the "c=" statement defining the actual multicast > > address. > > > > Another solution would be to require that MIKEY be used in conjunction > > with a separate authentication system which authenticates the > > entire SDP > > definition. (For example, SIP defines some authentication using PGP > > although I've heard comments that on one actually uses it.) This seems > > to me to be the safest approach, but it is too bad that MIKEY would be > > dependent on other systems. > > > > I'm anxious to hear your comments. > > > > Thanks, > > Brian > > -- > > Brian Weis > > Strategic Cryptographic Development, ITD, Cisco Systems > > Telephone: +1 408 526 4796 > > Email: bew@cisco.com > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 05:44:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00973 for ; Mon, 14 Jan 2002 05:44:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA02030; Mon, 14 Jan 2002 05:43: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 FAA01996 for ; Mon, 14 Jan 2002 05:43:45 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00968 for ; Mon, 14 Jan 2002 05:43:41 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0EAhgJ02660 for ; Mon, 14 Jan 2002 11:43:42 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Jan 14 11:43:20 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jan 2002 11:34:38 +0100 Message-ID: <0DAEDF148988D411BB980008C7E65D2E04FE3F9A@esealnt416> From: "Fredrik Lindholm (ERA)" To: "'Brian Weis'" , "'Mark Baugher'" Cc: msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, =?iso-8859-1?Q?Mats_N=E4slund_=28ERA=29?= , "'Rolf Blom'" Date: Mon, 14 Jan 2002 11:43:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: RE: MIKEY mapping of keys to steams -- possible vulnerabilit y 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 Brian, Mark, "Independence of the security of the underlying transport" means that no security mechanism of the underlying transport is used to protect the MIKEY message. However, the intention was not to let people think that MIKEY would solve all the problems that will come from using SIP, RTSP and SDP. I guess the formulation may be a bit misguiding, but I will put a clarification of this. More comments below. > > > 3) An idea, similar to the one you proposed. Instead of > including the hash of some specific field, a hash over a > well-defined subset or the entire SDP description could be > provided (but not as input to any id), i.e. set q = hash(the > sdp lines, except "a=keymgmt-data:..."). Let the > signature/MAC in MIKEY include q. The hash could in this case > be as just another payload in MIKEY. It would of course be > authenticated and the result would be equal to that in 2). > This will however have the same NAT problems as in 2). This > approach will have the disadvantage that we might need to > build in too much knowledge about SDP in MIKEY. > > Yes, I think that no matter what you choose to hash you'll either have > too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in > SDP. In the example above, who does the hash() on the local system? If > the SDP code does it then it has to know about creating a > MIKEY-specific > hash. If the MIKEY code does it, then it has to be given access to the > entire SDP description and it has to know how to parse it. > > This applies to both solutions 2) and 3). You can think of it as a > protocol layering violation problem. > Ok, put it like this. Some stuff that exists in SDP must be duplicated and put in MIKEY, e.g. IP address(es), and ports. This is a very common thing to put in a key management protocol, and are in general not treated as a layer violation. Then if you choose to hash it or not, that's another issue. The big issue resulting from this discussion as I see it (not only for MIKEY but to all key management protocols for secure groups) is, how do we treat NATs? If a NAT exists, you cannot bind IP addresses and ports in the key management scheme in a good way. In theory, I guess it would be possible to launch an attack (equal to Brian's where the SDP were changed), by fooling the NAT to map the incoming stream from a group wrong (assuming as Brian did that SOA is not used). This is an issue that we will look more into. I guess that NAT traversal may be a topic for a general MSEC discussion and a new thread. Some drafts on the NAT vs SDP/UDP topic from the mmusic group: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt Fredrik _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 16:06:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19162 for ; Mon, 14 Jan 2002 16:06:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25229; Mon, 14 Jan 2002 16:06:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA25196 for ; Mon, 14 Jan 2002 16:06:21 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19117 for ; Mon, 14 Jan 2002 16:06:17 -0500 (EST) Received: from mira-sjc5-6.cisco.com (mira-sjc5-6.cisco.com [171.71.163.23]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0EL5jF04310; Mon, 14 Jan 2002 13:05:45 -0800 (PST) Received: from mbaugher-w2k1.cisco.com (sjc-vpn3-479.cisco.com [10.21.65.223]) by mira-sjc5-6.cisco.com (Mirapoint) with ESMTP id AAQ43835; Mon, 14 Jan 2002 13:05:17 -0800 (PST) Message-Id: <4.3.2.7.2.20020114125733.06aa4930@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 14 Jan 2002 13:03:42 -0800 To: "Fredrik Lindholm (ERA)" From: Mark Baugher Subject: Re: [MMUSIC] RE: RE: MIKEY mapping of keys to steams -- possible vulnerabilit y Cc: "'Brian Weis'" , msec@securemulticast.org, "'mmusic@ietf.org'" , "Elisabetta Carrara (ERA)" , jari.arkko@ericsson.com, Mats =?iso-8859-1?Q?N=E4slund?= (ERA) , "'Rolf Blom'" In-Reply-To: <0DAEDF148988D411BB980008C7E65D2E04FE3F9A@esealnt416> 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 After exchanging some private notes and considering the nature of an attack using the CS identifiers, I don't think the issue that I raised about security dependencies between MIKEY and SDP amounts to very much. thanks, Mark At 11:43 AM 1/14/2002 +0100, Fredrik Lindholm (ERA) wrote: >Brian, Mark, > >"Independence of the security of the underlying >transport" means that no security mechanism of >the underlying transport is used to protect the >MIKEY message. However, the intention was not >to let people think that MIKEY would solve all >the problems that will come from using SIP, RTSP >and SDP. I guess the formulation may be a bit >misguiding, but I will put a clarification of >this. > >More comments below. > > > > > > 3) An idea, similar to the one you proposed. Instead of > > including the hash of some specific field, a hash over a > > well-defined subset or the entire SDP description could be > > provided (but not as input to any id), i.e. set q = hash(the > > sdp lines, except "a=keymgmt-data:..."). Let the > > signature/MAC in MIKEY include q. The hash could in this case > > be as just another payload in MIKEY. It would of course be > > authenticated and the result would be equal to that in 2). > > This will however have the same NAT problems as in 2). This > > approach will have the disadvantage that we might need to > > build in too much knowledge about SDP in MIKEY. > > > > Yes, I think that no matter what you choose to hash you'll either have > > too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in > > SDP. In the example above, who does the hash() on the local system? If > > the SDP code does it then it has to know about creating a > > MIKEY-specific > > hash. If the MIKEY code does it, then it has to be given access to the > > entire SDP description and it has to know how to parse it. > > > > This applies to both solutions 2) and 3). You can think of it as a > > protocol layering violation problem. > > > > >Ok, put it like this. Some stuff that exists in >SDP must be duplicated and put in MIKEY, e.g. IP >address(es), and ports. This is a very common >thing to put in a key management protocol, and >are in general not treated as a layer violation. >Then if you choose to hash it or not, that's >another issue. > >The big issue resulting from this discussion as >I see it (not only for MIKEY but to all key >management protocols for secure groups) is, how >do we treat NATs? If a NAT exists, you cannot >bind IP addresses and ports in the key management >scheme in a good way. In theory, I guess it would >be possible to launch an attack (equal to Brian's >where the SDP were changed), by fooling the NAT >to map the incoming stream from a group wrong >(assuming as Brian did that SOA is not used). >This is an issue that we will look more into. I >guess that NAT traversal may be a topic for a >general MSEC discussion and a new thread. > >Some drafts on the NAT vs SDP/UDP topic from the >mmusic group: >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt >http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt > > >Fredrik > > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 17: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 RAA23005 for ; Mon, 14 Jan 2002 17: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 RAA29103; Mon, 14 Jan 2002 17:42: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 RAA29063 for ; Mon, 14 Jan 2002 17:42: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 RAA22956; Mon, 14 Jan 2002 17:42: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 OAA26912; Mon, 14 Jan 2002 14:41:56 -0800 (PST) Message-ID: <3C435ED9.EBE9D82B@cisco.com> Date: Mon, 14 Jan 2002 17:42:34 -0500 From: Flemming Andreasen X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Kyzivat CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@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 Paul Kyzivat wrote: > Flemming Andreasen wrote: > > > > It doesn't solve this particular problem by itself, however it provides a > > mechanism that can be used to help solve it while remaining backwards > > compatible. In its present form, you can send an INVITE/offer listing only one > > codec in the "m=" line, and then include all codecs supported in the > > capabilites. The answerer can accept this, and then do another re-INVITE > > picking one or more codecs from the capabilites if you wants to use a different > > one. > > How about a variant of this - an Invite where the offer includes *no* m= > lines, but uses simcap to describe what is available. That wouldn't be backwards compatible or RFC 2327 conformant for that matter. > The recipient > would be expected to accept the invite with no media, perhaps also > returning capabilities. Then one side or the other need to send a > reinvite to establish media. > > This provides the extra round trip to do negotiation. But it requires > significant support from all parties. > Right. Apart from the above, I'm also not a big fan of requiring the extra round-trip. Default behavior should work with just a single round-trip, but further refinement (or changes) may require an extra round. > > An alternative that I was going to mention is to precede the INVITE with > an OPTIONS request to discover what the other side is capable of. But it > suffers from a serious problem - it doesn't establish a dialog, so there > is no guarantee that the subsequent INVITE will go to the same place. Right - good point (it's also SIP specific as opposed to more general offer/answer). -- Flemming > > > Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 18: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 SAA26172 for ; Mon, 14 Jan 2002 18:50: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 SAA01223; Mon, 14 Jan 2002 18:50: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 SAA01183 for ; Mon, 14 Jan 2002 18:50:22 -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 SAA26153; Mon, 14 Jan 2002 18:50:18 -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 g0ENo2418140; Mon, 14 Jan 2002 18:50:02 -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 AAA52438 (AUTH pkyzivat); Mon, 14 Jan 2002 18:52:30 -0500 (EST) Message-ID: <3C436D86.C11A0FED@cisco.com> Date: Mon, 14 Jan 2002 18:45:10 -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: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@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 - more comments below. Paul Flemming Andreasen wrote: > > Paul Kyzivat wrote: > > > Flemming Andreasen wrote: > > > > > > It doesn't solve this particular problem by itself, however it provides a > > > mechanism that can be used to help solve it while remaining backwards > > > compatible. In its present form, you can send an INVITE/offer listing only one > > > codec in the "m=" line, and then include all codecs supported in the > > > capabilites. The answerer can accept this, and then do another re-INVITE > > > picking one or more codecs from the capabilites if you wants to use a different > > > one. > > > > How about a variant of this - an Invite where the offer includes *no* m= > > lines, but uses simcap to describe what is available. > > That wouldn't be backwards compatible or RFC 2327 conformant for that matter. Why? It is legal to negotiate a media-less session. And an SDP body constitutes an offer even if it doesn't contain any m= lines. This would of course mean that the capability descriptions would all have to be session-level. So, the offer would contain a request for a session with no media, but with capability descriptions for supported media. The response would agree to the session with no media and return capability descriptions. Then one side or the other would initiate a re-invite, offering media compatible with the capabilities supported by both sides. > > > The recipient > > would be expected to accept the invite with no media, perhaps also > > returning capabilities. Then one side or the other need to send a > > reinvite to establish media. > > > > This provides the extra round trip to do negotiation. But it requires > > significant support from all parties. > > > > Right. Apart from the above, I'm also not a big fan of requiring the extra > round-trip. Default behavior should work with just a single round-trip, but further > refinement (or changes) may require an extra round. Well, you only do this if you don't know what to offer initially. You can also implement half of this techique: if you receive an offer with media that you can't support, you could accept the invite but refuse the media, and include a simcap description of what you would be willing to accept. Then hope for a reinvite. If the offerer doesn't know how to deal with this, ought to send bye to media-less session. > > > > > An alternative that I was going to mention is to precede the INVITE with > > an OPTIONS request to discover what the other side is capable of. But it > > suffers from a serious problem - it doesn't establish a dialog, so there > > is no guarantee that the subsequent INVITE will go to the same place. > > Right - good point (it's also SIP specific as opposed to more general offer/answer). > > -- Flemming > > > > > > > Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 20:03: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 UAA27972 for ; Mon, 14 Jan 2002 20:03: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 UAA03820; Mon, 14 Jan 2002 20:01:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03787 for ; Mon, 14 Jan 2002 20:01:56 -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 UAA27919 for ; Mon, 14 Jan 2002 20:01:53 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g0F11t132646 for ; Mon, 14 Jan 2002 20:01:55 -0500 Message-Id: <200201150101.g0F11t132646@chiron.nge.isi.edu> To: mmusic@ietf.org Date: Mon, 14 Jan 2002 20:01:55 -0500 From: Colin Perkins Subject: [MMUSIC] MMUSIC minutes Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org The MMUSIC minutes, and copies of slides, are now available from http://www.dmn.tzi.org/ietf/mmusic/ Colin _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 14 22:33: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 WAA02942 for ; Mon, 14 Jan 2002 22:33: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 WAA08411; Mon, 14 Jan 2002 22:33: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 WAA08373 for ; Mon, 14 Jan 2002 22:33:15 -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 WAA02898; Mon, 14 Jan 2002 22:33:10 -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 TAA05394; Mon, 14 Jan 2002 19:32:30 -0800 (PST) Message-ID: <3C43A2EE.1C9F8842@cisco.com> Date: Mon, 14 Jan 2002 22:33: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: Paul Kyzivat CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@cisco.com> <3C436D86.C11A0FED@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 Paul Kyzivat wrote: > Flemming - more comments below. > > Paul > > Flemming Andreasen wrote: > > > > Paul Kyzivat wrote: > > > > > Flemming Andreasen wrote: > > > > > > > > It doesn't solve this particular problem by itself, however it provides a > > > > mechanism that can be used to help solve it while remaining backwards > > > > compatible. In its present form, you can send an INVITE/offer listing only one > > > > codec in the "m=" line, and then include all codecs supported in the > > > > capabilites. The answerer can accept this, and then do another re-INVITE > > > > picking one or more codecs from the capabilites if you wants to use a different > > > > one. > > > > > > How about a variant of this - an Invite where the offer includes *no* m= > > > lines, but uses simcap to describe what is available. > > > > That wouldn't be backwards compatible or RFC 2327 conformant for that matter. > > Why? It is legal to negotiate a media-less session. And an SDP body > constitutes an offer even if it doesn't contain any m= lines. This would > of course mean that the capability descriptions would all have to be > session-level. > You're right - my mistake. > > So, the offer would contain a request for a session with no media, but > with capability descriptions for supported media. The response would > agree to the session with no media and return capability descriptions. Or, if it was an old implementation, it might return an SDP with media streams and formats it's willing to support. > > Then one side or the other would initiate a re-invite, offering media > compatible with the capabilities supported by both sides. > > > > > > The recipient > > > would be expected to accept the invite with no media, perhaps also > > > returning capabilities. Then one side or the other need to send a > > > reinvite to establish media. > > > > > > This provides the extra round trip to do negotiation. But it requires > > > significant support from all parties. > > > > > > > Right. Apart from the above, I'm also not a big fan of requiring the extra > > round-trip. Default behavior should work with just a single round-trip, but further > > refinement (or changes) may require an extra round. > > Well, you only do this if you don't know what to offer initially. > OK, however there are other downsides to this: - How do you handle a 1xx response to the first INVITE ? - What do you do if it turns out that you don't have any media formats in common, and now the called party is being alerted and/or has already answered ? > > You can also implement half of this techique: if you receive an offer > with media that you can't support, you could accept the invite but > refuse the media, and include a simcap description of what you would be > willing to accept. Then hope for a reinvite. If the offerer doesn't know > how to deal with this, ought to send bye to media-less session. You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media formats in common, etc.) -- Flemming _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 15 06:30: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 GAA18135 for ; Tue, 15 Jan 2002 06:30: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 GAA00983; Tue, 15 Jan 2002 06:29:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00952 for ; Tue, 15 Jan 2002 06:29:21 -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 GAA18003; Tue, 15 Jan 2002 06:29:19 -0500 (EST) Message-Id: <200201151129.GAA18003@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, 15 Jan 2002 06:29:19 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-ipv6-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 : Support for IPv6 in SDP Author(s) : S. Olson et al. Filename : draft-ietf-mmusic-sdp-ipv6-00.txt Pages : 4 Date : 14-Jan-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-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-ipv6-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-ipv6-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: <20020114175552.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-ipv6-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020114175552.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 Jan 15 09:33:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24719 for ; Tue, 15 Jan 2002 09:33:46 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA07723; Tue, 15 Jan 2002 09:33: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 JAA07684 for ; Tue, 15 Jan 2002 09:33:15 -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 JAA24698; Tue, 15 Jan 2002 09:33:12 -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 g0FEWsI17909; Tue, 15 Jan 2002 09:32:54 -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 AAA54599 (AUTH pkyzivat); Tue, 15 Jan 2002 09:35:21 -0500 (EST) Message-ID: <3C443C71.AD511964@cisco.com> Date: Tue, 15 Jan 2002 09:28:01 -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: Flemming Andreasen CC: Jonathan Rosenberg , sip@ietf.org, sip-implementors@cs.columbia.edu, mmusic@ietf.org Subject: Re: [Sip-implementors] Re: [MMUSIC] supporting just one codec at a time References: <3C3B65A0.A88A474B@cisco.com> <3C3BD0C5.4030301@dynamicsoft.com> <3C3C5199.4444C8F2@cisco.com> <3C3C82D9.32BA8081@cisco.com> <3C435ED9.EBE9D82B@cisco.com> <3C436D86.C11A0FED@cisco.com> <3C43A2EE.1C9F8842@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 more comments below. Paul Flemming Andreasen wrote: > > OK, however there are other downsides to this: > - How do you handle a 1xx response to the first INVITE ? Nothing special - just keep waiting. > - What do you do if it turns out that you don't have any media formats in common, and now > the called party is being alerted and/or has already answered ? Just send a BYE I suppose. This isn't any different than if you send an INVITE without an offer, and the offer you receive isn't acceptable. > > > > > You can also implement half of this techique: if you receive an offer > > with media that you can't support, you could accept the invite but > > refuse the media, and include a simcap description of what you would be > > willing to accept. Then hope for a reinvite. If the offerer doesn't know > > how to deal with this, ought to send bye to media-less session. > > You could do this, but it sounds a little fragile to me (e.g. consider clipping, no media > formats in common, etc.) Yeah, it might me. I don't see this as a great solution. But then I wasn't seeing any great solutions being offered, so I thought I would throw it into the pot. The problem is bigger than "supporting just one codec at a time", and the solution should also be. The general problem is that negotiating media sessions is a lot more complex than just picking one or more codecs to use. E.g. we may need to choose from among different transports for the same kind of medium. (This is looking like it may be a problem with IM.) Paul _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 15 15:57: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 PAA13098 for ; Tue, 15 Jan 2002 15:57: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 PAA21921; Tue, 15 Jan 2002 15:52: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 PAA21887 for ; Tue, 15 Jan 2002 15:52:25 -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 PAA13003 for ; Tue, 15 Jan 2002 15:52:22 -0500 (EST) Received: from chiron (csp@localhost) by chiron.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g0FKqOd05874 for ; Tue, 15 Jan 2002 15:52:24 -0500 Message-Id: <200201152052.g0FKqOd05874@chiron.nge.isi.edu> To: mmusic@ietf.org Date: Tue, 15 Jan 2002 15:52:24 -0500 From: Colin Perkins Subject: [MMUSIC] WG last call: draft-ietf-mmusic-sdp-ipv6-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 This is to announce a working group last call on Support for IPv6 in SDP (draft-ietf-mmusic-sdp-ipv6-00.txt). Please send comments to the mailing list by Monday 21st January 2002. If no substantive comments are received by that time, we plan to submit this draft to the IESG for consideration as a proposed standard RFC. Colin ------- Forwarded Message >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 et al. > Filename : draft-ietf-mmusic-sdp-ipv6-00.txt > Pages : 4 > Date : 14-Jan-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-00.txt > ------- End of Forwarded Message _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 17 21:00: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 VAA17349 for ; Thu, 17 Jan 2002 21:00: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 UAA04448; Thu, 17 Jan 2002 20:59: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 UAA04414 for ; Thu, 17 Jan 2002 20:59:46 -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 UAA17334 for ; Thu, 17 Jan 2002 20:59:43 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 17 Jan 2002 17:59:13 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id RAA21797 for ; Thu, 17 Jan 2002 17:59:09 -0800 (PST) Date: Thu, 17 Jan 2002 17:59:08 -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] Agenda for Jan 23 RTSP 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 the teleconference on Wednesday, January 23 (9am PST). Please RSVP to me by 5pm PST on Monday. http://rtsp.org/2002/telecon/agenda23Jan.html Thanks Rob ------ Rtsp Tc Agenda23 Jan2002 Table of contents: * Last Telecon * Review Action Items/New Issues * Close Resolutions * This Telecon Last Telecon Review Action Items/New Issues * NEW ISSUE: Should timestamps increase while stream is paused? * ACTION ITEM: Rob: ping Dave Singer on #461083 and encourage future participation * NEW ISSUE: should interleave parameter require value? * ACTION ITEM: Tom: request new bug "clarify requirement that interleave requires value" Close Resolutions * [5]448521 URLs in Rtp-Info need to be quoted + RESOLVED: Go with proposed resolution, with semicolon and comma as "dangerous characters". * [6]449074 - RTP Seqnum offset in Pause Play response + RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement. * [7]461083 - Body w/o Content-Length clarification + RESOLVED: require Content-length always, and eliminate implicit body-length via connection: close. * [8]447404 - Errors in table in chapter 12 + RESOLVED: evaluate SIP table format and move to that unless someone objects (and justifies) * [9]477407 - Transport BNF, ; and unclearities + RESOLVED: BNF will require semicolon, no mandated ordering, and example will be added. Example should include multiple entries of same type. However, will prohibit duplicated fields within a type entry. * [10]477413 - Transport BNF: mode + RESOLVED: Rework BNF, fixing multiple problems not limited to allow outside quotes, but not inside quotes. Quotes are optional * [11]477416 - BNF error section 3.6 NPT + RESOLVED: require npt=, but have backwards-compatibility note. Need to check BNF to make sure that not having npt= can work, and make sure everyone is aware that may be confusion may result This Telecon * [12]477421 When to send response * [13]477423 Unclearities regarding pause with range * [14]477424 How to queue timed plays? * [15]477425 Inconsistency between timeformats * [16]477427 Transport model requirements * [17]477428 Priorites between aggregated & non cntrl References 5. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=448521 6. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=449074 7. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=461083 8. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=447404 9. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477407 10. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477413 11. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477416 12. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477421 13. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477423 14. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477424 15. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477425 16. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477427 17. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477428 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 18 02:33: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 CAA03045 for ; Fri, 18 Jan 2002 02:33: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 CAA28627; Fri, 18 Jan 2002 02:33: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 CAA28592 for ; Fri, 18 Jan 2002 02:33:29 -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 CAA03024 for ; Fri, 18 Jan 2002 02:33:26 -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 g0I7XRK06730 for ; Fri, 18 Jan 2002 08:33:27 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id IAA12077; Fri, 18 Jan 2002 08:33:27 +0100 Message-ID: <3C47CFC7.33550820@era.ericsson.se> Date: Fri, 18 Jan 2002 08:33:27 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [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] RTSP: RTP timestamps when playing after pause 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, At the RTSP teleconference last week we discussed what to do with RTP timestamps when you PAUSE, waits some time then do PLAY. I thought there was going to be a new bug report on sourceForge, has somebody forgotten? The following was my interpretation of the proposal for a solution. The RTP timestamp is equal to display time. So it you do pause, wait five seconds and then press play the timestamp will be 5 seconds later for the first packet when resuming. This behavior works fine when the play contains a range, for queued play following after each other, but not for resuming play. The reason is the delay between a user on the client side pressing pause and until the client stops receiving data packets. If the client then does resume play, i.e. play without range, the server will continue after the last packet sent. In this case the client needs to show first the packet arriving directly after pressing pause (which according to the used model is past time), and then correctly synchronize the new packet which has a significant offset in timestamp corresponding to the period of pause the server has seen. The solution to this is to not use resume play and instead say play from the point where user pressed pause. On the other side I don't believe any other model will not have worse problems. Regards Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 22 02:09: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 CAA12995 for ; Tue, 22 Jan 2002 02:09: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 CAA24218; Tue, 22 Jan 2002 02:08: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 CAA24186 for ; Tue, 22 Jan 2002 02:08:44 -0500 (EST) Received: from exchange1.nuera.com ([12.105.228.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12992 for ; Tue, 22 Jan 2002 02:08:42 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jan 2002 23:11:45 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , Flemming Andreasen Cc: mmusic@ietf.org, confctrl@ISI.EDU Subject: RE: [MMUSIC] resolving open issues in offer/answer Date: Mon, 21 Jan 2002 23:11:39 -0800 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 Sorry for the delay in reply I just got back from a month away. With regards to the introduction of an SDP ssrc parameter (as quoted in the email below).... Hasn't the inclusion of a ssrc parameter been proposed and shot down multiple times already? [For instance discussion preceding and at the London IETF] An SDP body indicates where media should be sent (i.e. identifies a sink); this parameter is proposing to include information about a logically associated source in the sink description. Don't get me wrong, I am all for being able to correlate a particular received RTP packet stream to a received SDP offer/answer body but I merely wished to point out that this is not the first time this has been proposed. Is the offer/answer model a sufficient subset of generate sdp-new model that this is change in model is possible? Regards, Robert > > >>1. change the ssrc when you send with the new codec set. > The receiver > >>can drop uneeded codecs when it sees the new ssrc. This > only works for > >>unicast. > >> > > > > Actually, I don't even think it does. If you have multiple senders > > sending > > media to you, how do you know which SSRC corresponds to > which sender ? > > Also, > > it is possible than an SSRC change might happen for other reasons > > (admittedly, we are getting down to a rather small window for this > > race). > > > Realistically, for this to work, you would need to include the actual > SSRC rather than simply waiting for a change in the ssrc. That would > resolve the issues you raise above, but requires an additional SDP > parameter. > > Its worth noting that there is another advantage of the ssrc > parameter, > which is that it will allow us to correlate a media stream from a > particular source to a specific dialog, in the event the demux is not > done at the port level. This will happen in the case where we have a > forked INVITE that results in two 200 OK. Each answerer will end up > sending to the same offererd port. Having something in the > answer, like > the ssrc, which will allow for disambiguation, would help. > > Of course, there is the associated ugliness with collisions > resulting in > a change in ssrc.... > > However, this proposal is worth further consideration. It gives us an > explicit, reliable, rapid way to associate media streams with > signaling, > and I think thats fairly valuable. I will admit that changing > SSRC might > introduce some confusion into systems; I welcome inputs on specific > problems it might cause. > > > >>2. change in set of codecs has to also be accompanied by a port > >> change; when you see data on the new port, you can unload > any unneeded codecs. > >> > > > > However, such a requirement interacts with resource reservation in a > > negative way so I'd rather not do that. Out-of-order > delivery could also > > lead to unnecesarry discard of some packets (small window again > > admittedly). > > > Good point on the resource reservation. It would also force SRTP > rekeying for the same reasons. There is also the general "don't use > addresses/ports for application layer indications" as these > eventually > get you in trouble with nat. No need to add more such things > at this time. > > > > > > Fundamentally, I don't believe the synchronization problem > can be solved > > completely and hence we end with a heuristic no matter what. In tha > > case, > > I'd prefer something very simply that doesn't rely on > SSRC's, sequence > > numbers or is tied to the specifics of the media stream in any other > > way. I > > will contend, that if the answerer sends a media packet and > an answer at > > time t, then in practice it is *very* likely that the media > packet will > > arrive no later than the answer at the offerer. In > practice, this means > > that > > the offerer MAY simply stop accepting according to the old > offer at the > > time > > it receives the answer. > > > This is more or less exactly what I proposed initially in the > meeting; I > just added 1m for safety. > > > > > > Also note that this issue applies equally well to the > answerer, i.e. at > > what > > point does the answerer stop accepting media according to the old > > offer/answer exchange (I don't believe there was any text > proposed for > > this). This problem is actually worse inasmuch as the > answerer doesn't > > know > > when/if the offerer actually got the answer (not that I'm > proposing it, > > but > > it's hard to see how you can solve this without a 3-way handshake). > > > The SSRC proposal above would solve that. > > > > > > One idea would be to put constraints on allowable operation > while there > > is > > an outstanding offer in place. More specifically, if the > current media > > stream has codecs X and Y as allowable codecs and the new offer has > > codec X > > and Z as allowable codecs, then you should not send media > with codec Y > > while > > the offer is outstanding. That way, the answerer can stop > listening for > > codec Y at the time the answer is sent. However, in practice this is > > probably not all that desirable, e.g. consider the case > where X is RFC > > 2833, > > and Y and Z are voice codecs, or the case where X is a high-bw codec > > needed > > for voiceband date transfer and Y and Z are codecs used for normal > > voice. > > > It also wouldn't work in the case where the new offer has no > codecs in > common with the old. Furthermore, if the intersecting codec > was not the > highest preference one, you would end up using this > intermediate codec > for just one RTT, that probably won't sound all that great. > > > -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 Jan 22 14:18: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 OAA05946 for ; Tue, 22 Jan 2002 14:18: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 OAA06057; Tue, 22 Jan 2002 14:18: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 OAA06026 for ; Tue, 22 Jan 2002 14:18:24 -0500 (EST) Received: from NS1.US.PRSERV.NET ([64.180.246.83]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05907 for ; Tue, 22 Jan 2002 14:18:20 -0500 (EST) From: sydney@vkistudios.org Message-Id: <200201221918.OAA05907@ietf.org> Reply-To: seo@vkistudios.org To: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Tue, 22 Jan 2002 11:21:54 -0800 Subject: [MMUSIC] ADV: Professional Internet Marketing 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 Professional Internet Marketing, VKI Studios 1-866-733-8899
1-866-733-8899 

 

_______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 23 02: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 CAA02928 for ; Wed, 23 Jan 2002 02: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 CAA13163; Wed, 23 Jan 2002 02:35: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 CAA13126 for ; Wed, 23 Jan 2002 02:35:50 -0500 (EST) Received: from websmtp01.sohu.com ([61.135.132.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02905 for ; Wed, 23 Jan 2002 02:35:48 -0500 (EST) From: fyangyu@sohu.com Received: from mail.sohu.com (unknown [192.168.41.140]) by websmtp01.sohu.com (Postfix) with ESMTP id 9313F8FAD9 for ; Wed, 23 Jan 2002 15:32:38 +0800 (CST) Message-ID: <1337779.1011771131973.JavaMail.postfix@mailsrv11.mail.sohu.com> Date: Wed, 23 Jan 2002 15:32:11 +0800 (CST) To: Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-Mailer: Sohu Web MailComposer 2.0.12 Content-Transfer-Encoding: 8bit Subject: [MMUSIC] a qustion about draft-andreasen-mmusic-sdp-simcap-00 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 the draft-andreasen-mmusic-sdp-simcap-00.txt ,the author has pointed out the syntax and semantics for simple capability negotiation by use of SDP. What puzzle me is the negotiation precess.I think there must be some control mechanism to press the explosion of exchange of SDP packets. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 23 16: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 QAA27404 for ; Wed, 23 Jan 2002 16: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 QAA19370; Wed, 23 Jan 2002 16:53: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 QAA19337 for ; Wed, 23 Jan 2002 16:53:02 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27385 for ; Wed, 23 Jan 2002 16:52:59 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.88]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0NLr6Ge028724; Wed, 23 Jan 2002 16:53:06 -0500 (EST) Message-ID: <3C4F309F.59FC4A84@dynamicsoft.com> Date: Wed, 23 Jan 2002 16:52:31 -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: "Fairlie-Cuninghame, Robert" CC: Flemming Andreasen , mmusic@ietf.org, confctrl@ISI.EDU Subject: Re: [MMUSIC] resolving open issues 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 Fairlie-Cuninghame, Robert wrote: > Sorry for the delay in reply I just got back from a month away. > > With regards to the introduction of an SDP ssrc parameter (as quoted in > the > email below).... > > Hasn't the inclusion of a ssrc parameter been proposed and shot down > multiple times already? [For instance discussion preceding and at the > London > IETF] An SDP body indicates where media should be sent (i.e. identifies > a > sink); this parameter is proposing to include information about a > logically > associated source in the sink description. I think the usage in that other debate was different; there, it was one side INSTRUCTING the other side what SSRC to use, here, it is one side INFORMING the other side what SSRC it will use. In any event, I haven't proposed this. The conclusion of this thread was to document the three mechanisms we have discussed (change PT, change port, timer), as all three are local implementation decisions, and none of them may be needed in many cases anyhow. Text on that will appear in offer-answer -01 (actually, draft-ietf-mmusic-sdp-offer-answer-00) which will appear shortly after bis-06, next week hopefully. -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 Jan 23 21:49: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 VAA02636 for ; Wed, 23 Jan 2002 21:49: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 VAA28262; Wed, 23 Jan 2002 21:49:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA28227 for ; Wed, 23 Jan 2002 21:49:21 -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 VAA02632 for ; Wed, 23 Jan 2002 21:49:17 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Wed, 23 Jan 2002 18:48:48 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id SAA30474 for ; Wed, 23 Jan 2002 18:48:48 -0800 (PST) Date: Wed, 23 Jan 2002 18:49:47 -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 Jan 23 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 lightly edited minutes of the telecon. I'll send out more clearly worded versions of the resolutions to each of these in separate email. Attendees: please speak up if there are any errors or omissions. The minutes and agenda for this telecon and all other telecons can be found at the following address: http://rtsp.org/telecon/ (or, you can always find these by going to rtsp.org, clicking on "Process" in the left nav bar, and clicking on the "RTSP Ad Hoc Telecon Agenda and Minutes" link) Cheers, Rob Rtsp Tc Minutes23 Jan2002 _________________________________________________________________ 1. [1]Attendees 2. [2]Action items/new issues 3. [3]Discussion 1. [4]477421 When to send response 2. [5]477423 Unclearities regarding pause with range 3. [6]477424 How to queue timed plays? 4. [7]477425 Inconsistency between timeformats 5. [8]477427 Transport model requirements 6. [9]477428 Priorites between aggregated & non cntrl Attendees * Anders Klemets (AK) * Anne Jones (AJ) * Colin Perkins (CP) * Sean Sheedy (SS) * Magnus Westerlund (MW) * Joerg Ott (JO) * Milko Boic (MB) * Dave Walker (DW) * Rob Lanphier (RL) * Jonathan Sergent (JS) * Jeff Ayars (JA) 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. Discussion (following agenda at [10]http://rtsp.org/2002/telecon/agenda23Jan.html) 477421 When to send response [11]477421 * JS: may be more of a problem with TCP * RL: semantically correct should not disconnect, but syntax can cause disconnect * SS: should respond with seqnum-less response * JS: had to fix "bug" on our implementation on this when we blew away connection * MW: higher version number response * JS: should respond with good response * JS: what should be res on 421 * JA: send response with no seqnum * AK: question of when * JA: huge implementation issue to enforce order * JA: corner case not worth handling well * AK: should respond immediately? * JA: yes...at least not required to respond in request order. * AK: leave as implementation issue * JS: agreed * RL: has anyone implemented RTSP over UDP? * SS: Yes, implemented RTSP over UDP * RESOLVED: server allowed to send immediate response with no sequence number. server should NOT set sequence number 477423 Unclearities regarding pause with range [12]477423 * MB: pause with range gives you a "loose" range * JS: is that useful? * MB: if the time for the pause is already past? * JS: should avoid changing semantics * MW: what about UTC? * JS: I don't think you can specify UTC * JS: anyone implement UTC stuff * RL: not us * AJ: not us * MW: we have * JS: you may be only one. We need to forbid mixing * SS: we implemented * MW: we can remove this for pause * JS: you could want to use with nothing but UTC * RESOLVED: no UTC on pause. End of range is ignored (begin time is used). Example is needed. If both are specified a precedence is needed (time= takes precedence over clock) End of range is ignored (begin time is used). Example is needed. If multiple range specifiers are present, we need to come up with an ordering (npt/smpte takes precence over time) 477424 How to queue timed plays? [13]477424 queued play * JS: who implements * SS: we implement, but no client * JS: lets take it out * AK: there's other problems * MW: there may be some benefit, but not really as is * SS: usually, clients want to have immediately play * JS: PAUSE/PLAY can be pipelined * SS: eliminate queued play * JA: some VOIP folks would like it * JS: should take to list * 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 477425 Inconsistency between timeformats [14]477425 * JS: agree with note in 477425 * RESOLVED: Extend this to other time formats, and probably clarify the semantics of this particular syntax. Should start at pause point or the beginning. 477427 Transport model requirements [15]477427 * JS: We close things down, but we'd like to fix that * RL: how does liveness indication work * JS: we use RTCP * JS: Darwin hangs up if RTCP isn't received. * AJ: Correct. Some firewalls don't work well with this. * MW: There's a PING method request * TM: security issues with connectionless * JS: ssl is the way to solve this if that's a big issue * MW: what about original issue? * JS: needs to be negotiable option * MW: Use spec terminology: "persistent" and "non-persistent" * JS: Pragma specifically removed. * AK: perhaps "Supported" should be used * RESOLVED: define header and response for non-persistent connections. Default is connection-oriented, and connectionless MAY be implemented. Look into "supported" header. 477428 Priorites between aggregated & non cntrl [16]477428 * TM: we have "Required", suggest "Requested" * JS: what happenes when the client does SETUP audio, SETUP video, PLAY audio, all on same session * JS: perhaps adding MUTE would solve a lot of problems that overloading PAUSE causes * RL: what about TEARDOWN on stream URL? * JS: only sensible answer is that TEARDOWN on stream only tears down * RESOLVED: await resolution of queued play. Aggregate control issue needs larger discussion * ACTION ITEM: JS: Write up aggregate URL proposal. References 1. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line3 2. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line17 3. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line23 4. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line27 5. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line48 6. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line67 7. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line85 8. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line90 9. http://rtsp.org/2002/telecon/minutes23Jan.html?template=plain#line108 10. http://rtsp.org/2002/telecon/agenda23Jan.html 11. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477421 12. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477423 13. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477424 14. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477425 15. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477427 16. http://sourceforge.net/tracker/index.php?func=detail&group_id=23194&atid=377744&aid=477428 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 23 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 VAA02666 for ; Wed, 23 Jan 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 VAA28331; Wed, 23 Jan 2002 21:51: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 VAA28294 for ; Wed, 23 Jan 2002 21:51:41 -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 VAA02663 for ; Wed, 23 Jan 2002 21:51:37 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA01566; Wed, 23 Jan 2002 18:51:37 -0800 (PST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03343; Wed, 23 Jan 2002 18:51:36 -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 g0O2paPh018823; Wed, 23 Jan 2002 18:51:36 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0O2paht018822; Wed, 23 Jan 2002 18:51:36 -0800 (PST) Date: Wed, 23 Jan 2002 18:51:36 -0800 From: Jonathan Sergent To: Rob Lanphier Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Minutes from Jan 23 telecon Message-ID: <20020123185136.B18778@vernors> References: 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 Wed, Jan 23, 2002 at 06:49: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, Jan 23, 2002 at 06:49:47PM -0800, Rob Lanphier wrote: > * ACTION ITEM (JS): Write up aggregate URL proposal. I have this ready but want to proofread it before I send it out. Bug me if I don't get it out by the end of the week... _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Wed Jan 23 21:54: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 VAA02717 for ; Wed, 23 Jan 2002 21:54: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 VAA28395; Wed, 23 Jan 2002 21:54: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 VAA28360 for ; Wed, 23 Jan 2002 21:54: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 VAA02712 for ; Wed, 23 Jan 2002 21:54:31 -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 SAA20759; Wed, 23 Jan 2002 18:51:50 -0800 (PST) Message-ID: <3C4F76DA.19E7F206@cisco.com> Date: Wed, 23 Jan 2002 21:52:10 -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: fyangyu@sohu.com CC: mmusic@ietf.org Subject: Re: [MMUSIC] a qustion about draft-andreasen-mmusic-sdp-simcap-00 References: <1337779.1011771131973.JavaMail.postfix@mailsrv11.mail.sohu.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 fyangyu@sohu.com wrote: > In the draft-andreasen-mmusic-sdp-simcap-00.txt , Please note, that the current version is > the author has pointed out the syntax and semantics for simple capability negotiation by use of SDP. What puzzle me is the negotiation > precess.I think there must be some control mechanism to press the explosion of exchange of SDP packets. > The simcap draft does not define any negotiation mechanism, and, as has been pointed out in private, it would probably be more accurate to call it capability declaration. There has been some off-line discussion with the WG chairs about the need to define the relationship with offer/answer. -- Flemming > > _______________________________________________ > 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 Jan 24 03:59: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 DAA17854 for ; Thu, 24 Jan 2002 03:59: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 DAA18746; Thu, 24 Jan 2002 03:59: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 DAA18716 for ; Thu, 24 Jan 2002 03:59:17 -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 DAA17851 for ; Thu, 24 Jan 2002 03:59:14 -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 g0O8xFw13444; Thu, 24 Jan 2002 09:59:15 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA02276; Thu, 24 Jan 2002 09:59:15 +0100 Message-ID: <3C4FCCE2.EEB95D88@era.ericsson.se> Date: Thu, 24 Jan 2002 09:59:14 +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] Minutes from Jan 23 telecon 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, I think the resolution on the following issue is slightly bungled. > > 477423 Unclearities regarding pause with range > > [12]477423 > > * MB: pause with range gives you a "loose" range > * JS: is that useful? > * MB: if the time for the pause is already past? > * JS: should avoid changing semantics > * MW: what about UTC? > * JS: I don't think you can specify UTC > * JS: anyone implement UTC stuff > * RL: not us > * AJ: not us > * MW: we have > * JS: you may be only one. We need to forbid mixing > * SS: we implemented > * MW: we can remove this for pause > * JS: you could want to use with nothing but UTC > * RESOLVED: no UTC on pause. End of range is ignored (begin time is > used). Example is needed. If both are specified a precedence is > needed (time= takes precedence over clock) End of range is ignored > (begin time is used). Example is needed. If multiple range > specifiers are present, we need to come up with an ordering > (npt/smpte takes precence over time) > The resolution I thought we made was: Only a single range specifier on the format "value-" is allowed for pause. time="execution time in UTC" may also be used. I believe the ordering/processing of these two are very clear. Add example of how pause with range specifier is used. Regards Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 24 10:15: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 KAA23379 for ; Thu, 24 Jan 2002 10:15: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 KAA02612; Thu, 24 Jan 2002 10:15: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 KAA02571 for ; Thu, 24 Jan 2002 10:15: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 KAA23330; Thu, 24 Jan 2002 10:14:56 -0500 (EST) Message-Id: <200201241514.KAA23330@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, 24 Jan 2002 10:14:56 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-ipv6-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 : Support for IPv6 in SDP Author(s) : S. Olson et al. Filename : draft-ietf-mmusic-sdp-ipv6-01.txt Pages : 4 Date : 23-Jan-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-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-ipv6-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-ipv6-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: <20020123143220.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-sdp-ipv6-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020123143220.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 Jan 24 18:35:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09859 for ; Thu, 24 Jan 2002 18:35: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 SAA02276; Thu, 24 Jan 2002 18:34:54 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA02241 for ; Thu, 24 Jan 2002 18:34:51 -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 SAA09850 for ; Thu, 24 Jan 2002 18:34:43 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 24 Jan 2002 15:34:17 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id PAA01594; Thu, 24 Jan 2002 15:34:16 -0800 (PST) Date: Thu, 24 Jan 2002 15:35:14 -0800 (Pacific Standard Time) From: Rob Lanphier To: Magnus Westerlund cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Minutes from Jan 23 telecon In-Reply-To: <3C4FCCE2.EEB95D88@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, Thanks for the correction (my editing was obviously too light) :) Here's the corrected version I put online: 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. http://rtsp.org/2002/telecon/minutes23Jan.html#line48 Rob On Thu, 24 Jan 2002, Magnus Westerlund wrote: > Hi, I think the resolution on the following issue is slightly bungled. > > > > > > 477423 Unclearities regarding pause with range > > > > [12]477423 > > > > * MB: pause with range gives you a "loose" range > > * JS: is that useful? > > * MB: if the time for the pause is already past? > > * JS: should avoid changing semantics > > * MW: what about UTC? > > * JS: I don't think you can specify UTC > > * JS: anyone implement UTC stuff > > * RL: not us > > * AJ: not us > > * MW: we have > > * JS: you may be only one. We need to forbid mixing > > * SS: we implemented > > * MW: we can remove this for pause > > * JS: you could want to use with nothing but UTC > > * RESOLVED: no UTC on pause. End of range is ignored (begin time is > > used). Example is needed. If both are specified a precedence is > > needed (time= takes precedence over clock) End of range is ignored > > (begin time is used). Example is needed. If multiple range > > specifiers are present, we need to come up with an ordering > > (npt/smpte takes precence over time) > > > > The resolution I thought we made was: > Only a single range specifier on the format "value-" is allowed for pause. time="execution time in > UTC" may also be used. I believe the ordering/processing of these two are very clear. Add example of > how pause with range specifier is used. > > > Regards > > Magnus Westerlund > > Audio Technology, Ericsson Research > ---------------------------------------------------------------------- > Ericsson Radio Systems AB | Phone +46 8 4048287 > Torshamsgatan 23 | Fax +46 8 7575550 > S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.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 Thu Jan 24 19: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 TAA10285 for ; Thu, 24 Jan 2002 19:03: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 TAA03432; Thu, 24 Jan 2002 19:03: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 TAA03399 for ; Thu, 24 Jan 2002 19:02:59 -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 TAA10274 for ; Thu, 24 Jan 2002 19:02:57 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 24 Jan 2002 16:02:29 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id QAA15382 for ; Thu, 24 Jan 2002 16:02:28 -0800 (PST) Date: Thu, 24 Jan 2002 16:03:26 -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: eliminate queued play? (#508211) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi all, One item that came up in the RTSP teleconference is a proposal to eliminate the queued play feature from RTSP altogether. Queued playing, as describe in section 10.5, is a feature that has many problems with it (e.g. #477424) The members on the telecon felt that support for this feature is sufficiently weak that rather than fixing this feature, it may be more appropriate to eliminate it, and come up with a simpler play/pause model to replace it. What does everyone think about this? We'd like to make a decision on this quickly, so if there's no discussion on this list before February 6, we'd like to call this one settled (of course, if there is discussion, we'll let that play out first). Rob The writeup of the bug is at the following location: http://rtsp.org/bug508211 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 24 19:46: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 TAA10813 for ; Thu, 24 Jan 2002 19:46: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 TAA04800; Thu, 24 Jan 2002 19:46: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 TAA04765 for ; Thu, 24 Jan 2002 19:46:36 -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 TAA10796 for ; Thu, 24 Jan 2002 19:46:33 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA23554; Thu, 24 Jan 2002 16:46:35 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id QAA02382; Thu, 24 Jan 2002 16:47:56 -0800 (PST) Received: from moe (silveroak.Eng.Sun.COM [129.146.81.98]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0P0kY3f518953; Thu, 24 Jan 2002 16:46:34 -0800 (PST) Date: Thu, 24 Jan 2002 16:46:42 -0800 Subject: Re: [MMUSIC] Minutes from Jan 23 telecon Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: mmusic@ietf.org To: Rob Lanphier From: Jonathan Sergent In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 On Thursday, January 24, 2002, at 03:35 PM, Rob Lanphier wrote: > 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. Is it more useful to have time take precedence over npt/smpte/clock? For a PAUSE with Range: npt=foo;time=bar, the interpretation with npt precedence would be to pause the stream at npt foo and bar would be ignored. The interpretation with time precedence would be to pause the stream at time bar while setting the pause point to foo (regardless of what it was set to). Neither of these is particularly useful, IMO. I do think that PAUSE with only time= might be useful in a broadcast control scenario, to say that a program needs to end at a particular time, rather than at a particular point in the program, since the relationship between the two might be hard to determine from the client, especially if it isn't participating in the session, only controlling it. So upon further reflection it's my humble opinion that it is probably better to say for PAUSE that the Range header should contain (time= | npt= | smpte= | clock=) rather than (npt= | smpte= | clock=) (;time=)? ... But I could cope with the precedence as you have it above. It doesn't matter too much to me. -- Jonathan Sergent / sergent@Eng.Sun.COM / (650)352-6495 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 03:58:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27312 for ; Fri, 25 Jan 2002 03:58: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 DAA03324; Fri, 25 Jan 2002 03:56: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 DAA03291 for ; Fri, 25 Jan 2002 03:56:39 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27302 for ; Fri, 25 Jan 2002 03:56:35 -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 g0P8uTIB003119; Fri, 25 Jan 2002 09:56:29 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA09946; Fri, 25 Jan 2002 09:56:28 +0100 Message-ID: <3C511DBC.8DF304E6@era.ericsson.se> Date: Fri, 25 Jan 2002 09:56:28 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Sergent CC: Rob Lanphier , mmusic@ietf.org Subject: Re: [MMUSIC] Minutes from Jan 23 telecon 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 Jonathan, Rob See arguments below on the issue. Jonathan Sergent wrote: > On Thursday, January 24, 2002, at 03:35 PM, Rob Lanphier wrote: > > > 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. > > Is it more useful to have time take precedence over npt/smpte/clock? > I would say that doing that interpretation breaks backwards compatibility. My interpretation of the time= is that it has presedence. You do not execute the method until the your wall clock has reached the time specifed in time=. Then you look at the rest of the range togheter with the method. So I don't want us to change this for pause. > > For a PAUSE with Range: npt=foo;time=bar, the interpretation with npt > precedence would be to pause the stream at npt foo and bar would be > ignored. > > The interpretation with time precedence would be to pause the stream at > time bar while setting the pause point to foo (regardless of what it was > set to). > > Neither of these is particularly useful, IMO. I do think that PAUSE > with only time= might be useful in a broadcast control scenario, to say > that a program needs to end at a particular time, rather than at a > particular point in the program, since the relationship between the two > might be hard to determine from the client, especially if it isn't > participating in the session, only controlling it. > But to have a range header with only time is not allowed in todays syntax. But at least for pause specifying a point that you know the presentation/media has passed makes it equal to no range, i.e. pause immedeatly. > > So upon further reflection it's my humble opinion that it is probably > better to say for PAUSE that the Range header should contain > (time= | npt= | smpte= | clock=) > rather than > (npt= | smpte= | clock=) (;time=)? > ... My opinion is that such a change will result in more complexity, when range is interpreted in different ways between PLAY and PAUSE. -- Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 14:13: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 OAA11462 for ; Fri, 25 Jan 2002 14:13: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 OAA03919; Fri, 25 Jan 2002 14:13: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 OAA03886 for ; Fri, 25 Jan 2002 14:13:01 -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 OAA11452 for ; Fri, 25 Jan 2002 14:12:57 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24375; Fri, 25 Jan 2002 11:12:57 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id LAA14191; Fri, 25 Jan 2002 11:14:20 -0800 (PST) Received: from moe (vpn-129-150-6-51.EBay.Sun.COM [129.150.6.51]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0PJCs3f119308; Fri, 25 Jan 2002 11:12:55 -0800 (PST) Date: Fri, 25 Jan 2002 11:13:04 -0800 Subject: Re: [MMUSIC] Minutes from Jan 23 telecon Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: mmusic@ietf.org To: Magnus Westerlund From: Jonathan Sergent In-Reply-To: <3C511DBC.8DF304E6@era.ericsson.se> Message-Id: <8EB91EF0-11C7-11D6-A57C-003065F634E6@Eng.Sun.COM> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 On Friday, January 25, 2002, at 12:56 AM, Magnus Westerlund wrote: > I would say that doing that interpretation breaks backwards > compatibility. > My interpretation of the time= is that it has presedence. You do not > execute > the method until the your wall clock has reached the time specifed in > time=. > Then you look at the rest of the range togheter with the method. So I > don't > want us to change this for pause. This sounds fine to me, in particular the third and fourth sentences. --jss. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 16:34: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 QAA14913 for ; Fri, 25 Jan 2002 16:34: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 QAA11760; Fri, 25 Jan 2002 16:34: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 QAA11729 for ; Fri, 25 Jan 2002 16:34:00 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14901 for ; Fri, 25 Jan 2002 16:33:51 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Jan 25 16:33:26 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0PLXA340577; Fri, 25 Jan 2002 16:33:14 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA25466; Fri, 25 Jan 2002 16:33:08 -0500 (EST) Message-ID: <3C51CE29.FE50E31C@cs.columbia.edu> Date: Fri, 25 Jan 2002 16:29:13 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Rob Lanphier CC: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) 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 I would like to maintain this feature. Nobody has to implement it, but it is useful to ensure gap-less playback. The bug noted (477424) seems to apply only to the case that explicit activation times are listed, in which case queueing doesn't make sense. Thus, only requests without activitation time should be queued. What other problems are there? Rob Lanphier wrote: > > Hi all, > > One item that came up in the RTSP teleconference is a proposal to > eliminate the queued play feature from RTSP altogether. > > Queued playing, as describe in section 10.5, is a feature that has many > problems with it (e.g. #477424) The members on the telecon felt that > support for this feature is sufficiently weak that rather than fixing this > feature, it may be more appropriate to eliminate it, and come up with a > simpler play/pause model to replace it. > > What does everyone think about this? We'd like to make a decision on this > quickly, so if there's no discussion on this list before February 6, we'd > like to call this one settled (of course, if there is discussion, we'll > let that play out first). > > Rob > > The writeup of the bug is at the following location: > http://rtsp.org/bug508211 > > _______________________________________________ > 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 Jan 25 16:50: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 QAA15253 for ; Fri, 25 Jan 2002 16:50: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 QAA12650; Fri, 25 Jan 2002 16:49: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 QAA12615 for ; Fri, 25 Jan 2002 16:49:41 -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 QAA15239 for ; Fri, 25 Jan 2002 16:49:35 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Fri, 25 Jan 2002 13:48:58 -0800 Received: from jeffa-laptop.real.com ([172.23.106.160]) by prognet.com (8.9.2/8.9.0) with ESMTP id NAA05131; Fri, 25 Jan 2002 13:49:00 -0800 (PST) Message-Id: <4.3.2.7.2.20020125134621.053ac4d0@mail.real.com> X-Sender: jeffa@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Jan 2002 13:47:23 -0800 To: Henning Schulzrinne , Rob Lanphier From: Jeff Ayars Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) Cc: mmusic@ietf.org In-Reply-To: <3C51CE29.FE50E31C@cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org At 04:29 PM 1/25/2002 -0500, Henning Schulzrinne wrote: >I would like to maintain this feature. Nobody has to implement it, but >it is useful to ensure gap-less playback. The bug noted (477424) seems >to apply only to the case that explicit activation times are listed, in >which case queueing doesn't make sense. Thus, only requests without >activitation time should be queued. What other problems are there? How can you have a Draft Standard document with a feature without 2 implementations? If nobody implements it don't we have to take it out? JEff _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 17:08: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 RAA15783 for ; Fri, 25 Jan 2002 17: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 RAA13740; Fri, 25 Jan 2002 17:07:57 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA13706 for ; Fri, 25 Jan 2002 17:07:54 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15769 for ; Fri, 25 Jan 2002 17:07:49 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by dirty; Fri Jan 25 17:06:06 EST 2002 Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g0PM5t342823; Fri, 25 Jan 2002 17:05:55 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA26764; Fri, 25 Jan 2002 17:05:54 -0500 (EST) Message-ID: <3C51D5D6.A8ADF14D@cs.columbia.edu> Date: Fri, 25 Jan 2002 17:01:58 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Ayars CC: Rob Lanphier , mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) References: <4.3.2.7.2.20020125134621.053ac4d0@mail.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 Careless phrasing on my part: Yes, there have to be two implementations. No, it doesn't have to be mandatory-to-implement (MUST). Jeff Ayars wrote: > > At 04:29 PM 1/25/2002 -0500, Henning Schulzrinne wrote: > >I would like to maintain this feature. Nobody has to implement it, but > >it is useful to ensure gap-less playback. The bug noted (477424) seems > >to apply only to the case that explicit activation times are listed, in > >which case queueing doesn't make sense. Thus, only requests without > >activitation time should be queued. What other problems are there? > > How can you have a Draft Standard document with a feature without 2 > implementations? If nobody implements it don't we have to take it out? > > JEff _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 17:09: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 RAA15830 for ; Fri, 25 Jan 2002 17:09: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 RAA13800; Fri, 25 Jan 2002 17:08: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 RAA13771 for ; Fri, 25 Jan 2002 17:08:42 -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 RAA15807 for ; Fri, 25 Jan 2002 17:08:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09436 for ; Fri, 25 Jan 2002 15:08:39 -0700 (MST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18558 for ; Fri, 25 Jan 2002 14:08: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 g0PM8cPh020519 for ; Fri, 25 Jan 2002 14:08:38 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0PM8cU2020518 for mmusic@ietf.org; Fri, 25 Jan 2002 14:08:38 -0800 (PST) Date: Fri, 25 Jan 2002 14:08:38 -0800 From: Jonathan Sergent To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) Message-ID: <20020125140838.B20341@vernors> References: <3C51CE29.FE50E31C@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C51CE29.FE50E31C@cs.columbia.edu>; from hgs@cs.columbia.edu on Fri, Jan 25, 2002 at 04:29:13PM -0500 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 Fri, Jan 25, 2002 at 04:29:13PM -0500, Henning Schulzrinne wrote: > I would like to maintain this feature. Nobody has to implement it, but > it is useful to ensure gap-less playback. The bug noted (477424) seems > to apply only to the case that explicit activation times are listed, in > which case queueing doesn't make sense. Thus, only requests without > activitation time should be queued. What other problems are there? Right now it is a MUST for servers, but I am under the impression that nobody uses it, and there are servers which do not implement it even though it is a MUST. Could it be made optional for servers? Servers which don't implement it can just return errors for the second and further play requests so that the client can detect this. A Require tag could also be introduced for clients which absolutely need queued play in order to operate. -- Jonathan Sergent / sergent@Eng.Sun.COM _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 17:09: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 RAA15849 for ; Fri, 25 Jan 2002 17:09: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 RAA13897; Fri, 25 Jan 2002 17:09: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 RAA13833 for ; Fri, 25 Jan 2002 17:09:07 -0500 (EST) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15842; Fri, 25 Jan 2002 17:09:01 -0500 (EST) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g0PM8xB10623; Fri, 25 Jan 2002 17:08:59 -0500 (EST) Reply-To: From: "Eric Burger" To: , Cc: , , "Sipping" , Date: Fri, 25 Jan 2002 17:08:58 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Media Resource Control (MRCP) BOF 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 Multimedia Resource Control (mrcp) BOF Chairs ------ Eric Burger David Oran BOF Description ---------------- Many multimedia applications can benefit from having ASR and TTS processing available as a distributed, network resource. To date, there are a number of proprietary ASR and TTS API's, as well as two IETF drafts, that address this problem. However, there are serious deficiencies to the existing drafts relating to MRCP. In particular, they mix the semantics of existing protocols yet are close enough to other protocols as to be confusing to the implementer. The MRCP BOF will examine whether the IETF should charter a Working Group to develop protocols to support distributed media processing of audio streams. There are multiple IETF protocols for establishment and termination of media sessions (SIP), low-level media control (MGCP and megaco), and media record and playback (RTSP). The focus of this working group is to develop protocols to support Automated Speech Recognition (ASR) and rendering text into audio, a.k.a. Text-to-Speech (TTS). The working group will only focus on the distributed control of ASR and TTS servers. The working group will develop an informational RFC detailing the architecture and requirements for distributed ASR and TTS control. The working group will then examine existing media-related protocols, especially RTSP, for suitability as a protocol for carriage of ASR and TTS control. Then, the working group will propose extensions to existing protocols or the development of new protocols, as appropriate, to meet the requirements specified in the informational RFC. The protocol will assume RTP carriage of media. Assuming session-oriented media transport, the protocol will use SDP to describe the session. The working group will not be investigating distributed speech recognition (DSR), as exemplified by the ETSI Aurora project. The working group will not be recreating functionality available in other protocols, such as SIP or SDP. The working group will offer changes to existing protocols, with the possible exception of RTSP, to the appropriate IETF work group for consideration. This working group will explore modifications to RTSP, if required. The intention is to disband the work group within one year of chartering. Goals and Milestones -------------------- Mar 02 BOF at 53rd IETF Jul 02 Informational Requirements RFC Published Dec 02 Submit Internet Draft(s) Analyzing Existing Protocols Dec 02 Submit Internet Draft Describing New Protocol (if required) Mar 03 Drafts to IESG Reading List ------------ "MRCP: Media Resource Control Protocol", draft-shanmugham-mrcp-01.txt "Using Media Resource Control Protocol over SIP", draft-robinson-mrcp-sip-00.txt Mailing List ------------ The discussion list for MRCP is at mrcp@snowshore.com. To subscribe, send a request to: majordomo@snowshore.com with subscribe mrcp in the body. The list archive is at http://flyingfox.snowshore.com/mrcp_archive/maillist.html N.B.: This list replaces the mrcp@external.cisco.com list. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 17:16: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 RAA16088 for ; Fri, 25 Jan 2002 17:16: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 RAA14194; Fri, 25 Jan 2002 17:16: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 RAA14159 for ; Fri, 25 Jan 2002 17:16:11 -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 RAA16063; Fri, 25 Jan 2002 17:16:05 -0500 (EST) Message-Id: <200201252216.RAA16063@ietf.org> To: IETF-Announce: ; Cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com From: The IESG Reply-to: iesg@ietf.org Date: Fri, 25 Jan 2002 17:16:05 -0500 Subject: [MMUSIC] Last Call: Support for IPv6 in SDP 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 Multiparty Multimedia Session Control Working Group to consider Support for IPv6 in SDP as a Proposed Standard. 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 February 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 17:40: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 RAA17021 for ; Fri, 25 Jan 2002 17:40: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 RAA15317; Fri, 25 Jan 2002 17:40: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 RAA15269 for ; Fri, 25 Jan 2002 17:40:19 -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 RAA17016 for ; Fri, 25 Jan 2002 17:40:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27356 for ; Fri, 25 Jan 2002 15:40:15 -0700 (MST) Received: from vernors.eng.sun.com (vernors.Eng.Sun.COM [129.146.81.112]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10286 for ; Fri, 25 Jan 2002 14:40:11 -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 g0PMeBPh020736 for ; Fri, 25 Jan 2002 14:40:11 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0PMeBlM020735 for mmusic@ietf.org; Fri, 25 Jan 2002 14:40:11 -0800 (PST) Date: Fri, 25 Jan 2002 14:40:11 -0800 From: Jonathan Sergent To: mmusic@ietf.org Message-ID: <20020125144011.F20341@vernors> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [MMUSIC] Mixing aggregate and non-aggregate control (long) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org We began to identify some issues with mixing various combinations of aggregate control, non-aggregate control, queued play and "muting" in the same session during the last RTSP conference call. I wrote this up to try to explain some of the conflicts between the way these features are defined in the RFC. The initial connection setup is the same for all of the scenarios. There are 13 scenarios, which seems fitting. If this is too much for you to digest, you can skip to the end, where I have outlined some proposed resolutions to the problems as I see them. Please let me know where my mistakes are... Thanks in advance, -- Jonathan Sergent / sergent@Eng.Sun.COM Initial connection setup is as follows: -------------------------------------------------------------------- C->S DESCRIBE rtsp://host/a RTSP/1.0 Cseq: 1 Accept: application/sdp -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 1 Content-Type: application/sdp Content-Base: rtsp://host/a/ Content-Length: 190 v=0 o=jsergent 1 8750 IN IP4 129.146.81.112 s=Example c=IN IP4 0/32 t=3162748440 0 a=control:* a=range:npt=0-60 m=audio 0 RTP/AVP 5 a=control:b a=ptime:40 m=video 0 RTP/AVP 26 a=control:c -------------------------------------------------------------------- C->S SETUP rtsp://host/a/b RTSP/1.0 Cseq: 2 Transport: RTP/AVP/UDP;unicast;client_port=5004-5005 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 2 Session: ZZEfpZ0zxK5 Transport: RTP/AVP/UDP;unicast;client_port=5004-5005;server_port=65118-65119 -------------------------------------------------------------------- C->S SETUP rtsp://host/a/c RTSP/1.0 Cseq: 3 Session: ZZEfpZ0zxK5 Transport: RTP/AVP/UDP;unicast;client_port=5006-5007 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 3 Session: ZZEfpZ0zxK5 Transport: RTP/AVP/UDP;unicast;client_port=5006-5007;server_port=65118-65119 -------------------------------------------------------------------- Scenario #1: Normal aggregate control Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/ RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0- -------------------------------------------------------------------- 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 -------------------------------------------------------------------- This is the normal aggregate control scenario. Both streams are sent, in sync, to the client. Scenario #2: Mixed non-aggregate control on "aggregate presentation" Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/b RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (at time t) RTSP/1.0 200 OK Cseq: 4 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 -------------------------------------------------------------------- C->S (before time t+10) PLAY rtsp://host/a/c RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (before time t+10) RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992 -------------------------------------------------------------------- This is the scenario that bug #? mentions. The question is what the second PLAY request should do. My interpretation of the RFC, as currently written, is that this play should be queued, so that the result is that the server streams the first ten seconds of the audio, immediately transitions, and then streams the first ten seconds of the video. There is nothing in the RFC to suggest that you cannot start playing using PLAY of a single stream even if you have done SETUP for multiple streams. (Perhaps I am missing something...) Assuming that queued play is reasonable (which it might not be, but that is another discussion), this scenario actually seems somewhat reasonable. (For example, it's feasible that a more advanced description format than SDP might be able to indicate to the client that two streams are meant for sequential rather than simultaneous viewing.) Issues: (1) Does queued play make sense? Should we remove it entirely? (2) If multiple streams have been setup, should PLAY with a range header be permitted for an individual stream URL rather than the entire presentation URL? Pure non-aggregate control would still be permitted, but each stream would need to be in its own presentation. (3) Should there be a queue for each URL used with PLAY, or one queue for each RTSP session? If the queue is per-URL instead of per-session, then it is unclear what do do if the client PAUSEs a different URL than it PLAYed. Scenario #3: Mixed non-aggregate control without range headers Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/b RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (at time t) RTSP/1.0 200 OK Cseq: 4 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 -------------------------------------------------------------------- C->S (before time t+10) PLAY rtsp://host/a/c RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- I do not know what the server should do in this case. I see a few options. i. Play the first ten seconds of the audio, then immediately transition to the video. The video plays for the range "npt=10-". ii. Play the first ten seconds of the audio, then immediately transition to the video. The video plays for the range "npt=0-". iii. This is a liveness ping (as in section 10.5). The language at the bottom of page 34 says "a stream" but does not say that the stream you send the PLAY request for must be the one that is playing. iv. Add the video stream in sync with the audio stream when the PLAY arrives. (This might be useful, but the spec doesn't seem to endorse it.) v. Error. Issues: (4) Does a liveness ping (as in section 10.5) require the specified URL to be the same as the one that is currently playing? (5) Is it possible to queue a PLAY with no time range? (probably.) (6) Is there one pause point for each URL used with PLAY or one for each RTSP session, in the case where different URLs are used with PLAY? Scenario #4: Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/b RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (at time t) RTSP/1.0 200 OK Cseq: 4 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 -------------------------------------------------------------------- C->S (after time t+10) PLAY rtsp://host/a/c RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- I do not know what the server should do in this case. I see similar options to scenario #3. i. Play the first ten seconds of the audio, then immediately transition to the video. The video plays for the range "npt=10-". ii. Play the first ten seconds of the audio, then immediately transition to the video. The video plays for the range "npt=0-". Issues: (7) Is the answer to #6 any different when the PLAY request is not queued? Hopefully not. Scenario #5: Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/ RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0- -------------------------------------------------------------------- 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 + 5) PAUSE rtsp://host/a/b RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- C->S (time = t + 30) PLAY rtsp://host/a/b RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- See second sentence of section 10.6. The server plays the entire presentation except that the audio is "muted" from time 5 until time 30. 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. Scenario #7: 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 -------------------------------------------------------------------- C->S (time = t + 10) PAUSE rtsp://host/a/ RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- This is like #6, except that the PAUSE request stops the streaming immediately and cancels the PLAY request with Cseq 5. Scenario #8: 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 -------------------------------------------------------------------- C->S (time = t + 10) PAUSE rtsp://host/a/b RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- This should mute the audio at t+10. But should it cancel the queued play request from Cseq 5? "A PAUSE request discards all queued PLAY requests." Issues: (8) Does PAUSE discard all queued PLAY requests, or does it only do so if the URL specified is the one that is currently playing? Scenario #9 Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/b RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (at time t) RTSP/1.0 200 OK Cseq: 4 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 -------------------------------------------------------------------- C->S (before time t+10) PLAY rtsp://host/a/c RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (before time t+10) RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992 -------------------------------------------------------------------- C->S (before time t+10) PAUSE rtsp://host/a/c RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C (before time t+10) RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- Isn't this getting tiresome by now? Good for you if you read this far. This is scenario #2 with a PAUSE appended. This PAUSE should clearly cancel the queued PLAY from Cseq 5. But should it PAUSE the currently executing PLAY from Cseq 4? This is another facet of issue #8. Scenario #10 Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/b RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (at time t) RTSP/1.0 200 OK Cseq: 4 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 -------------------------------------------------------------------- C->S (before time t+10) PLAY rtsp://host/a/c RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- S->C (before time t+10) RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992 -------------------------------------------------------------------- C->S (before time t+10) PAUSE rtsp://host/a/b RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C (before time t+10) RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- The PAUSE with Cseq 6 should mute the audio from Cseq 4. Should it also cancel the PLAY from Cseq 5? This is another permutation of issue #8. The URL that is queued might be different from the one that is playing, and it is unclear if that changes the answer. Scenario #11: Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/ RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- 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 + 5) PAUSE rtsp://host/a/b RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- C->S (time = t + 15) PLAY rtsp://host/a/ RTSP/1.0 Cseq: 6 Range: npt=0-10 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914, url=rtsp://host/a/c;seq=16778;rtptime=1946900992 -------------------------------------------------------------------- The PAUSE just mutes the audio. At time 10, the video stops too because of the closed range from the first PLAY. The server will start playing both streams after the second PLAY. If the PAUSE really was a mute, it would make sense for it to stay muted... there is no indication that this should happen, though. Scenario #12: Initial connection setup, followed by: -------------------------------------------------------------------- C->S PLAY rtsp://host/a/ RTSP/1.0 Cseq: 4 Session: ZZEfpZ0zxK5 Range: npt=0-10 -------------------------------------------------------------------- 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 + 9.99) PLAY rtsp://host/a/ RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C ??? -------------------------------------------------------------------- The interpretation of the request with Cseq 5 will be different depending on how fast the network is. If the PLAY request is processed by the server before time 10, it is a liveness ping. Otherwise, it starts the stream playing again from npt=10. Issues: (9) There is a race condition possible between sending a liveness ping and the end of the currently playing range that can cause liveness pings to be interpreted as requests to start playing from the pause point. Scenario #13: 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 + 5) PAUSE rtsp://host/a/b RTSP/1.0 Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 5 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- C->S (time = t + 10) PAUSE rtsp://host/a/c RTSP/1.0 Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C RTSP/1.0 200 OK Cseq: 6 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- C->S (time = t + 15) PLAY rtsp://host/a/ RTSP/1.0 Cseq: 7 Session: ZZEfpZ0zxK5 -------------------------------------------------------------------- S->C ??? -------------------------------------------------------------------- What does the PLAY with Cseq 7 do? In this case, the presentation is started and *both* streams are muted. Does muting all of the streams pause the session, or is the session alive but with all streams muted? The wording about muting in 10.6 is unclear. Possibilities for the PLAY: i. Start playing both streams immediately from npt 10. ii. Queue the PLAY until Cseq 4 is complete. At time t+30, unmute both streams and keep playing. iii. Liveness ping. Nothing happens. A future PLAY on one of the stream URLs will unmute it. There are probably more scenarios than I have gone through. -------------------------------------------------------------------- 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". _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 18:42:12 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18151 for ; Fri, 25 Jan 2002 18:42: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 SAA18094; Fri, 25 Jan 2002 18:41: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 SAA18065 for ; Fri, 25 Jan 2002 18:41:48 -0500 (EST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18146 for ; Fri, 25 Jan 2002 18:41:44 -0500 (EST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Fri, 25 Jan 2002 15:41:16 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 25 Jan 2002 15:41:16 -0800 Received: from red-msg-01.redmond.corp.microsoft.com ([157.54.12.68]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 25 Jan 2002 15:41:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [MMUSIC] RTSP: eliminate queued play? (#508211) Date: Fri, 25 Jan 2002 15:41:15 -0800 Message-ID: <5F961F00D4E6F649958381D0ED3F19FC045311C3@red-msg-01.redmond.corp.microsoft.com> Thread-Topic: [MMUSIC] RTSP: eliminate queued play? (#508211) Thread-Index: AcGl7OGXEyQYkuajR9aXCafa0/gJgAADHfTA From: "Anders Klemets" To: "Jonathan Sergent" , X-OriginalArrivalTime: 25 Jan 2002 23:41:16.0023 (UTC) FILETIME=[C7C6F870:01C1A5F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA18066 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 > Right now it is a MUST for servers, but I am under the impression that > nobody uses it, and there are servers which do not implement it even > though it is a MUST. Could it be made optional for servers? Servers > which don't implement it can just return errors for the second and > further play requests so that the client can detect this. A Require > tag could also be introduced for clients which absolutely need queued > play in order to operate. Yes, this is a possible solution. But unless there are two independent interoperable implementations, it shouldn't be in the Draft Standard RFC at all. I think there could be one or more additional RFC's (Experimental Status) that define optional extensions to RTSP, such as this one. These additional RFC's could progress towards standards status independently of the main RTSP RFC. Another problem with queued PLAYs, is that the server typically won't be able to respond with the Rtp-Info header unless the PLAY is starting immediately. So in order for the client to get the Rtp-Info header belonging to a queued PLAY request, the server may have to send some kind of command to the client. Maybe the server could send a SET_PARAMETER command to the client, and this command would include the Rtp-Info header. In any case, RFC-2326 doesn't explain at all how this is supposed to be accomplished. Anders _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 20:18: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 UAA19328 for ; Fri, 25 Jan 2002 20:18: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 UAA21312; Fri, 25 Jan 2002 20:17: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 UAA21281 for ; Fri, 25 Jan 2002 20:17:27 -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 UAA19323 for ; Fri, 25 Jan 2002 20:17:24 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Fri, 25 Jan 2002 17:16:56 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id RAA16765; Fri, 25 Jan 2002 17:16:55 -0800 (PST) Date: Fri, 25 Jan 2002 17:17:53 -0800 (Pacific Standard Time) From: Rob Lanphier To: Henning Schulzrinne cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) In-Reply-To: <3C51CE29.FE50E31C@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org Hi Henning, Regarding the two implementation discussion, the issue is that we don't feel like it's likely we'll have two clients and two servers for this feature. On the telecon, we tallied one server and no clients. That's hardly an exhaustive search, but that's also part of the point of this thread. If there's someone on this list who knows of client implemenations of this feature, they need to speak up. As I remember it, Jonathan Sergent noted on the telecon that he has a raft of issues he plans to write up if we decide to keep queued play. I'll let him go into it further. Just doing a search on "queue" in the bugs, I find the following: http://rtsp.org/bug477424 How to queue timed plays? http://rtsp.org/bug477428 Priorites between aggregated & non cntrl http://rtsp.org/bug477432 RTP info and queued plays http://rtsp.org/bug493265 Pause - Play behaviour clarification http://rtsp.org/bug507882 RTP timestamps when playing after pause That's not to say that all of these speak to the issue at hand, so don't take this as the definitive list. In general, it seemed that most of the people on the call would rather come up with a simplified PLAY/PAUSE model than to work out the bugs with the current feature. Rob On Fri, 25 Jan 2002, Henning Schulzrinne wrote: > I would like to maintain this feature. Nobody has to implement it, but > it is useful to ensure gap-less playback. The bug noted (477424) seems > to apply only to the case that explicit activation times are listed, in > which case queueing doesn't make sense. Thus, only requests without > activitation time should be queued. What other problems are there? > > Rob Lanphier wrote: > > > > Hi all, > > > > One item that came up in the RTSP teleconference is a proposal to > > eliminate the queued play feature from RTSP altogether. > > > > Queued playing, as describe in section 10.5, is a feature that has many > > problems with it (e.g. #477424) The members on the telecon felt that > > support for this feature is sufficiently weak that rather than fixing this > > feature, it may be more appropriate to eliminate it, and come up with a > > simpler play/pause model to replace it. > > > > What does everyone think about this? We'd like to make a decision on this > > quickly, so if there's no discussion on this list before February 6, we'd > > like to call this one settled (of course, if there is discussion, we'll > > let that play out first). > > > > Rob > > > > The writeup of the bug is at the following location: > > http://rtsp.org/bug508211 > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Fri Jan 25 21:04: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 VAA19773 for ; Fri, 25 Jan 2002 21:04: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 VAA23113; Fri, 25 Jan 2002 21:03: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 VAA23082 for ; Fri, 25 Jan 2002 21:03:36 -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 VAA19769 for ; Fri, 25 Jan 2002 21:03:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10392 for ; Fri, 25 Jan 2002 18:03:33 -0800 (PST) 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 SAA20227 for ; Fri, 25 Jan 2002 18:03:33 -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 g0Q23XPh021090 for ; Fri, 25 Jan 2002 18:03:33 -0800 (PST) Received: (from jsergent@localhost) by vernors.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g0Q23XQO021089 for mmusic@ietf.org; Fri, 25 Jan 2002 18:03:33 -0800 (PST) Date: Fri, 25 Jan 2002 18:03:32 -0800 From: Jonathan Sergent To: mmusic@ietf.org Subject: Re: [MMUSIC] RTSP: eliminate queued play? (#508211) Message-ID: <20020125180332.A21083@vernors> References: <3C51CE29.FE50E31C@cs.columbia.edu> 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 Fri, Jan 25, 2002 at 05:17:53PM -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 Fri, Jan 25, 2002 at 05:17:53PM -0800, Rob Lanphier wrote: > As I remember it, Jonathan Sergent noted on the telecon that he has a raft > of issues he plans to write up if we decide to keep queued play. I'll let > him go into it further. Just doing a search on "queue" in the bugs, I > find the following: Even if we don't keep it, there are lots of issues. I just sent the list out this afternoon. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Jan 26 03:29: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 DAA03815 for ; Sat, 26 Jan 2002 03:29: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 DAA13141; Sat, 26 Jan 2002 03:29: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 DAA13110 for ; Sat, 26 Jan 2002 03:29:28 -0500 (EST) Received: from www16-cn.sinonets.net.cn ([202.99.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03799 for ; Sat, 26 Jan 2002 03:29:23 -0500 (EST) From: info@polyglot.com.cn Received: from An [218.19.24.52] by www16-cn.sinonets.net.cn (SMTPD32-6.06) id A86670200F0; Sat, 26 Jan 2002 16:27:18 +0800 Date: ÐÇÆÚÁù, 26 Ò»Ô 2002 16:29:37 +0800 Content-Type: text/plain To: mmusic@ietf.org X-Library: WinShoes 7.035B X-Mailer: MSEND 1.01A Message-Id: <200201261627687.SM01104@An> Subject: [MMUSIC] Polyglot Translation רҵ·­Òë 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 Polyglot Translation Co., Ltd. We are a professional translation organization that provides translation, interpretation, and simultaneous meeting interpretation in all fields. In addition, we provide localization of websites into Chinese, writing articles in multi-languages, foreign languages recording, proofreading, Interpreters/translators recommending, website designing and making and so on. We can provide a large variety of languages translating services such as English, Japanese, French, German, Russian, Korean, Italian, Spanish, Dutch, Swedish, Finnish, Portuguese, Czechish, Slovak,Romanian, Polish, Hungarian,Bulgarian,Arabic,Turkish,Cambodian, Malay, Indonesian, Thai, Vietnamese, Nepali, Laotian, Burmese, Mongolian, Indic, Bengalese, Tamil and so on. Altogether, we can provide more than 30 languages translation service fast and accurately. For the details, please visit our website: http://www.polyglot.com.cn http://www.chinapolyglot.com Contact us: E-mail: info@polyglot.com.cn Tel: +86-20-86573608 Fax: +86-20-86573965 Add: Rm. 968 Office Tower Central Hotel 33 Airport Road, Guangzhou, China The message below is written in Chinese characters: ±£Á¢ÐÅ·­Ò빫˾ ±£Á¢ÐÅ·­Ò빫˾ÊÇÒ»¼Òרҵ·­Òë»ú¹¹,¿ÉÌṩ¸÷¸öÁìÓòµÄ±ÊÒë¡¢¿ÚÒë¡¢»áÒé µÄͬÉù´«Òë¡£ ´ËÍ⣬Ϊ¸÷ÀàÖÐÍâÍøÕ¾Ìṩ·­Òë°æ±¾£¬ÒÔ¼°Îª¿Í»§Ìṩ¶àÖÖÓïÑÔµÄ׫¸å·þÎñ¡¢ ÍâÎļÒô¡¢Ð£¸å¡¢·­ÒëÍƼö¡¢ÍøÕ¾Éè¼Æ¡¢ÖÆ×÷µÈ¡£ ·­ÒëÓïÖÖ£º¿ÉÌṩӢ¡¢ÈÕ¡¢·¨¡¢µÂ¡¢¶í¡¢º«¡¢Òâ´óÀû¡¢Î÷°àÑÀ¡¢ºÉÀ¼¡¢Èðµä¡¢ ·ÒÀ¼¡¢ÆÏÌÑÑÀ¡¢½Ý¿Ë¡¢Ë¹Âå·¥¿Ë¡¢ÂÞÂíÄáÑÇ¡¢²¨À¼¡¢ÐÙÑÀÀû¡¢±£¼ÓÀûÑÇ¡¢°¢À­²®¡¢ ÍÁ¶úÆä¡¢¼íÆÒÕ¯¡¢ ÂíÀ´¡¢Ó¡Äᡢ̩¡¢Ô½ÄÏ¡¢Äá²´¶û¡¢ ÀÏÎΡ¢Ãåµé¡¢Ãɹš¢Ó¡¶È¡¢ ÃϼÓÀ­¡¢Ì©Ã׶ûµÈÈýÊ®¶àÃÅÍâÓï×î׼ȷ¡¢¿ì½ÝµÄ·­ÒëµÄ·þÎñ¡£ ¹ØÓÚÏêÇ飬Çë²Î¹ÛÎÒÃǵÄÍøÖ·£º http://www.polyglot.com.cn http://www.chinapolyglot.com ÁªÏµ·½Ê½£º µçÓÊ: info@polyglot.com.cn µç»°: 020-86573608 ´«Õæ: 020-86573965 µØÖ·£ºÖйú¹ãÖÝ»ú³¡Â·33ºÅÖÐÑë¾Æµêд×ÖÂ¥968 Óʱࣺ510403 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sat Jan 26 20:42: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 UAA13085 for ; Sat, 26 Jan 2002 20:42: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 UAA13671; Sat, 26 Jan 2002 20:42: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 UAA13641 for ; Sat, 26 Jan 2002 20:42:16 -0500 (EST) Received: from yourwebsite.com (ip68-3-250-165.ph.ph.cox.net [68.3.250.165]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13059 for ; Sat, 26 Jan 2002 20:42:10 -0500 (EST) From: stacie2180655@hotmail.com Message-Id: <200201270142.UAA13059@ietf.org> Reply-To: stacie2180655@hotmail.com To: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Sat, 26 Jan 2002 18:50:20 -0800 Subject: [MMUSIC] Come Join The Fun 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 I am Stacie I have live shows from my dorm at http://www.contentchat.com/sirjive/ Join me and talk to me one on one .....You won't regret it I am the hottest thing on the net and I am waiting for you to join me and tell me what you want me to do ... Come see me at http://www.contentchat.com/sirjive/ Love me STACIE _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Sun Jan 27 12:14: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 MAA01440 for ; Sun, 27 Jan 2002 12:14: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 MAA18362; Sun, 27 Jan 2002 12:13: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 MAA18331 for ; Sun, 27 Jan 2002 12:13:31 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01413; Sun, 27 Jan 2002 12:13:26 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0RHCxU07003; Sun, 27 Jan 2002 19:12:59 +0200 Date: Sun, 27 Jan 2002 19:12:59 +0200 (EET) From: Pekka Savola To: iesg@ietf.org cc: mmusic@ietf.org, , In-Reply-To: <200201252216.RAA16063@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] Re: Last Call: Support for IPv6 in SDP 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 On Fri, 25 Jan 2002, The IESG wrote: > The IESG has received a request from the Multiparty Multimedia Session > Control Working Group to consider Support for IPv6 in SDP > as a Proposed Standard. > > 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 February 8, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt In the draft: --8<-- 5. Example SDP description with IPv6 addresses The following is an example SDP description using the above ABNF for IPv6 addresses. In particular, the origin, URI, and connection fields contain IPv6 addresses. The URI contains an IPv4 compatible IPv6 address. v=0 o=nasa1 971731711378798081 0 IN IP6 2201:056D::112E:144A:1E24 s=(Almost) live video feed from Mars-II sattelite u=http://[::FFFF:10.2.12.126]/marsII p=+1 713 555 1234 c=IN IP6 FF00:03AD::7F2E:172A:1E24 t=3338481189 3370017201 m=audio 6000 RTP/AVP 2 a=rtpmap:2 G726-32/8000 m=video 6024 RTP/AVP 107 a=rtpmap:107 H263-1998/90000 --8<-- There are several issues with this: 1) I don't think it's good practise to use these addresses in an example, I'd rather use: - 3FFE:FFFF::112E:144A:1E24 (as 2201 TLA hasn't been assigned yet and we don't know if there would be some special meaning for it in the future) - FF0E:03AD::7F2E:172A:1E24 (global, not reserved scope) 2) s/The URI contains an IPv4 compatible IPv6 address/The URI contains an IPv4-mapped address/ in the header, or change u=. 3) IMO, it's a bit questionable to use IPv4-mapped addresses like this anyway. IPv4-mapped addresses should only be used (apart from e.g. SIIT definition) as a node's internal representation for IPv4 address; for better compatibility, the node should use: u=http://10.2.12.126/marsII (this way the receiving IPv6 node can decide the mechanism to reach the IPv4-address; that is, if u= can contain either IPv4 or IPv6 address) Also: --8<-- IP6-multicast = hexpart [ ":" IP4-multicast ] "/" ttl [ "/" integer ] ; IPv6 address starting with FF00 --8<-- 1) 'ttl' is not defined anywhere? (rather obvious though); (_TTL_ is not defined in IPv6 anyway, though.) 2) IPv6-multicast address does not need to start with FF00; anything beginning with FF is syntactically ok. 3) The full list of ABNF notations could be split to "normative" and "informative" (e.g. of the latter, in this context, IP4-address, b1, b4, perhaps others), but that's a matter of opinion/clarity I guess. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 04:06: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 EAA20871 for ; Mon, 28 Jan 2002 04:06: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 EAA28872; Mon, 28 Jan 2002 04:05: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 EAA28839 for ; Mon, 28 Jan 2002 04:05:05 -0500 (EST) Received: from aifhs8.alcatel.fr (aifhs8.alcatel.fr [212.208.74.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20852 for ; Mon, 28 Jan 2002 04:05:01 -0500 (EST) From: Laurent.Thiebaut@alcatel.fr Received: from frmail14.netfr.alcatel.fr (frmail14.netfr.alcatel.fr [155.132.251.14]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with ESMTP id KAA19825; Mon, 28 Jan 2002 10:04:09 +0100 (MET) To: Seancolson@yahoo.com, Gonzalo.camarillo@ericsson.com, mmusic@ietf.org, ipng@sunroof.eng.sun.com Date: Mon, 28 Jan 2002 10:04:06 +0100 Message-ID: X-MIMETrack: Serialize by Router on FRMAIL14/FR/ALCATEL(Release 5.0.8 |June 18, 2001) at 01/28/2002 10:04:09 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [MMUSIC] Re: Last Call: Support for IPv6 in SDP 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 May be I have missed something, but does the proposal allow a DSTM node to propose an IPV4 and an IPV6 @ for the "Connection data" address? Another way of expressing my question, does the proposal cope with a host offering to its peer to dialog either in IPV4 or in IPV6 for the exchange of the media content? Thanks in advance for the clarification Best regards Laurent T. --------------------------------------------------------------------------- V Laurent Thiebaut tel: +33 (0)1 3077 0645 A L C A T E L e.mail:laurent.thiebaut@alcatel.fr --------------------------------------------------------------------------- The IESG on 25/01/2002 23:16:05 Please respond to iesg@ietf.org To: IETF-Announce: ; cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com(bcc: Laurent THIEBAUT/FR/ALCATEL) Subject: Last Call: Support for IPv6 in SDP to Proposed Standard The IESG has received a request from the Multiparty Multimedia Session Control Working Group to consider Support for IPv6 in SDP as a Proposed Standard. 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 February 8, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 04:40:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21333 for ; Mon, 28 Jan 2002 04: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 EAA00359; Mon, 28 Jan 2002 04:40: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 EAA00325 for ; Mon, 28 Jan 2002 04:40:15 -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 EAA21328 for ; Mon, 28 Jan 2002 04:40:11 -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 g0S9eB315811; Mon, 28 Jan 2002 10:40:11 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA22865; Mon, 28 Jan 2002 10:38:29 +0100 Message-ID: <3C551C14.68F2EB5F@era.ericsson.se> Date: Mon, 28 Jan 2002 10:38:28 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Sergent CC: mmusic@ietf.org Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) References: <20020125144011.F20341@vernors> 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, other RTSP interested, I have some comments inline. Jonathan Sergent wrote: > Initial connection setup is as follows: > > -------------------------------------------------------------------- > C->S > DESCRIBE rtsp://host/a RTSP/1.0 > Cseq: 1 > Accept: application/sdp > > -------------------------------------------------------------------- > S->C > RTSP/1.0 200 OK > Cseq: 1 > Content-Type: application/sdp > Content-Base: rtsp://host/a/ > Content-Length: 190 > > v=0 > o=jsergent 1 8750 IN IP4 129.146.81.112 > s=Example > c=IN IP4 0/32 > t=3162748440 0 > a=control:* > a=range:npt=0-60 > m=audio 0 RTP/AVP 5 > a=control:b > a=ptime:40 > m=video 0 RTP/AVP 26 > a=control:c > -------------------------------------------------------------------- > C->S > SETUP rtsp://host/a/b RTSP/1.0 > Cseq: 2 > Transport: RTP/AVP/UDP;unicast;client_port=5004-5005 > > -------------------------------------------------------------------- > S->C > RTSP/1.0 200 OK > Cseq: 2 > Session: ZZEfpZ0zxK5 > Transport: RTP/AVP/UDP;unicast;client_port=5004-5005;server_port=65118-65119 > > -------------------------------------------------------------------- > C->S > SETUP rtsp://host/a/c RTSP/1.0 > Cseq: 3 > Session: ZZEfpZ0zxK5 > Transport: RTP/AVP/UDP;unicast;client_port=5006-5007 > > -------------------------------------------------------------------- > S->C > RTSP/1.0 200 OK > Cseq: 3 > Session: ZZEfpZ0zxK5 > Transport: RTP/AVP/UDP;unicast;client_port=5006-5007;server_port=65118-65119 > > -------------------------------------------------------------------- > > Scenario #2: Mixed non-aggregate control on "aggregate presentation" > Initial connection setup, followed by: > -------------------------------------------------------------------- > C->S > PLAY rtsp://host/a/b RTSP/1.0 > Cseq: 4 > Session: ZZEfpZ0zxK5 > Range: npt=0-10 > > -------------------------------------------------------------------- > S->C (at time t) > RTSP/1.0 200 OK > Cseq: 4 > Session: ZZEfpZ0zxK5 > RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 > > -------------------------------------------------------------------- > C->S (before time t+10) > PLAY rtsp://host/a/c RTSP/1.0 > Cseq: 5 > Session: ZZEfpZ0zxK5 > Range: npt=0-10 > > -------------------------------------------------------------------- > S->C (before time t+10) > RTSP/1.0 200 OK > Cseq: 5 > Session: ZZEfpZ0zxK5 > RTP-Info: url=rtsp://host/a/c;seq=16778;rtptime=1946900992 > > -------------------------------------------------------------------- > > This is the scenario that bug #? mentions. No, it is not the scenario my bug report mention. If the second play had been made on url:"rtsp://host/a" then it would be my bug report. > The question is what the > second PLAY request should do. My interpretation of the RFC, as > currently written, is that this play should be queued, so that the > result is that the server streams the first ten seconds of the audio, > immediately transitions, and then streams the first ten seconds of the > video. I don't agree on that interpretation. If you compare this with true non-aggregated, i.e. separate rtsp sessions, the second play would be done immediately and not queued as it is on another media. > > There is nothing in the RFC to suggest that you cannot start playing > using PLAY of a single stream even if you have done SETUP for multiple > streams. (Perhaps I am missing something...) > > Assuming that queued play is reasonable (which it might not be, but > that is another discussion), this scenario actually seems somewhat > reasonable. (For example, it's feasible that a more advanced > description format than SDP might be able to indicate to the client > that two streams are meant for sequential rather than simultaneous > viewing.) > > Issues: > (1) Does queued play make sense? Should we remove it entirely? > (2) If multiple streams have been setup, should PLAY with a range > header be permitted for an individual stream URL rather than the > entire presentation URL? Pure non-aggregate control would still be > permitted, but each stream would need to be in its own > presentation. > (3) Should there be a queue for each URL used with PLAY, or one > queue for each RTSP session? If the queue is per-URL instead of > per-session, then it is unclear what do do if the client PAUSEs > a different URL than it PLAYed. > > Scenario #4: > Initial connection setup, followed by: > -------------------------------------------------------------------- > C->S > PLAY rtsp://host/a/b RTSP/1.0 > Cseq: 4 > Session: ZZEfpZ0zxK5 > Range: npt=0-10 > > -------------------------------------------------------------------- > S->C (at time t) > RTSP/1.0 200 OK > Cseq: 4 > Session: ZZEfpZ0zxK5 > RTP-Info: url=rtsp://host/a/b;seq=15914;rtptime=420914 > > -------------------------------------------------------------------- > C->S (after time t+10) > PLAY rtsp://host/a/c RTSP/1.0 > Cseq: 5 > Session: ZZEfpZ0zxK5 > > -------------------------------------------------------------------- > > I do not know what the server should do in this case. > > I see similar options to scenario #3. > i. Play the first ten seconds of the audio, then immediately transition > to the video. The video plays for the range "npt=10-". > ii. Play the first ten seconds of the audio, then immediately transition > to the video. The video plays for the range "npt=0-". > > Issues: > (7) Is the answer to #6 any different when the PLAY request is not > queued? Hopefully not. > I would argue for case ii without the words immediately transition. As the second play happens when no other play is active the media should start playing when the request is received by the server. And as it is rangeless and no pause was the command prior it starts playing npt=0-. > > Scenario #5: > Initial connection setup, followed by: > -------------------------------------------------------------------- > C->S > PLAY rtsp://host/a/ RTSP/1.0 > Cseq: 4 > Session: ZZEfpZ0zxK5 > Range: npt=0- > > -------------------------------------------------------------------- > 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 + 5) > PAUSE rtsp://host/a/b RTSP/1.0 > Cseq: 5 > Session: ZZEfpZ0zxK5 > > -------------------------------------------------------------------- > S->C > RTSP/1.0 200 OK > Cseq: 5 > Session: ZZEfpZ0zxK5 > > -------------------------------------------------------------------- > C->S (time = t + 30) > PLAY rtsp://host/a/b RTSP/1.0 > Cseq: 6 > Session: ZZEfpZ0zxK5 > > -------------------------------------------------------------------- > S->C > RTSP/1.0 200 OK > Cseq: 6 > Session: ZZEfpZ0zxK5 > > -------------------------------------------------------------------- > > See second sentence of section 10.6. The server plays the entire > presentation except that the audio is "muted" from time 5 until time > 30. > This usage seems to be in some contradiction with normal behavior regarding queued plays. Your suggested introduction of MUTE and UNMUTE is good. They remove some of the overloading on the commands that has created the ambiguous behavior. > > 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. 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 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. 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. Of course we should clarify that options/set_parameter with session id also shall keep the time-out counter updated. I don't know if people is aware that 3GPP standard for packet base streaming TS 26.234 (from v.4.20) which uses RTSP recommends that options with session id is used for keep alive. Regards Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 08:54: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 IAA25650 for ; Mon, 28 Jan 2002 08:54: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 IAA10810; Mon, 28 Jan 2002 08:53: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 IAA10761 for ; Mon, 28 Jan 2002 08:53:27 -0500 (EST) Received: from mail.datang.com (mail.datang.com [202.100.9.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25616 for ; Mon, 28 Jan 2002 08:53:17 -0500 (EST) From: chenshx@mail.datang.com Received: from HOST ([202.100.9.118]) by mail.datang.com (8.11.0/8.11.0) with SMTP id g0SDlgj16859 for ; Mon, 28 Jan 2002 21:47:42 +0800 Date: Mon, 28 Jan 2002 21:47:42 +0800 Message-Id: <200201281347.g0SDlgj16859@mail.datang.com> To: mmusic@ietf.org Subject: [MMUSIC] new photos from my party! 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! My party... It was absolutely amazing! I have attached my web page with new photos! If you can please make color prints of my photos. Thanks! begin 666 www.myparty.yahoo.com M35J0``,````$````__\``+@`````````0``````````````````````````` M````````````````````@`````X?N@X`M`G-(;@!3,TA5&AIP$`0``BT4,4U97BP"CH`%!`.@0!!2_^V?W!&0)`<#XA;?>2;.S5P]1E>!\CY#;?OQR$3'(/$$%H2P5[#PU%MV1*V M43W4&#W^?MFUFX)J`FJS-Q;<#(U%^%`>L+;%#.I9%AC_=?C-_37L"A7\4:-H M=#Y6$G;]]NYCC;R+3?AT,]([P;`[5?QT""?[OHO/%8T$"8D-H%`]Q/E&&Q9[ MUB"E\VJ%V&$AH@`9IF6Y+=O+`/TSV\8'_VX4Q`9+LS5;#`%A!@)P`[-U#S=S M:-A5_\E0$01+LS1;=`8%909R!R=;LS1`"&=""0I;<[)T#6P+#"YK#>;O9#L^ M#@],B)T0/&+?=J@8#.(4OL@&FP'W9L]D)0!0L08O[K\-/QL-CC_ MT/?Q.<;&_S?2!9P7?'0,COUAK003*T.#QP0[+W+6]]L1-@M;%8/L(E=J9(`E M-T-C8^$`7Y_\91G!FM']2W=H`,GW`8")??C'1?0)`.Z&6[EZE"%8=5/(BS68 M#!]==VN0&FCX/%`R]`9U9,R9[OS_UB(G.1^0F\T-&>`$2YSK#C<6C&0*HY91 MB/[#>P0`&FQ9DQ]\@4`4;`??_0N[+5`4;A"+\/"-KYU?5MR24R"* MPX!EFJYSO_P$,8A%_LG-C`/P_MW)YMA`4*(SF!X::-AWLKI`45`;=`H@UH>' M,?:%?/L#?+(/6Y"47ZQ9<'//;,<%#U"]>\EL4,"I@[U\$@(/E,#U36B#P61P M$&`=>1O(KTP%G%"!G&AX2>J:!AVF%!!0EB62(>P#SJ?135Z23#$CSV%=7\5EN1P;8.\G80/$$/@D$E/%H/ASDWG&W`H7;R_8NLP>OR\N)5?0"[`C> M+E&V=SA%"83`,XB$%8OM;K\00D$?=NDA@*0/NCW^[&^]!C!\#0@Y#XYH`CV% MO^;K#"D>C0Q)28`$,,+);N:$21YJ+MS<9U]@9ZXQ-H/I`S<10IX<81\$\0$J M)3D9!='V"ME"0@UYMCI82');I2P5AZ!N4/N^BS7)&2YV2HJ$-14\]&6S\$*A M.7X@J7Q^&`NW%G8'6GZQ0-X\+C$\P=G9VRUT#U]U%$-&6CL<9I:^@7*_ZP?8 M"%[V+Y=,LO\P"G\&1_8D5_:#_P5_1-DY70C"X"#0W/,(1'4NOB.;#G9TT?\V M]X.,#GPC"VQ,QFH]X$#L"`?^[#6)7>1V;:T*'ORW3SP*68AFWHL-%DZ)!(V3=!7_2;$-!B?448-99_A& MN-W4Y3MU@I/\%[O(#^CTA5S:R_B&>0&-#!CFR0.Y@QC^20%!`=GT+;1YTT@'P#"`T@\#X>`KY!GD$3"@(==?@-+MQ@4YR".]I<"(O#=A?_ MEVW;=3#=!S\P=`=(.\)W[NL#C3YA_]-X`I?#`\H[V7,8(4`[P7*M,[U=!$BK M"(7_B\B#2-]J'VYZA*79]CL+Q?2+SW=\>0ZD&)(U1DT(=N@Y\A$KEPT%/2^[ MHB6)`S-\/5#N,!BD`Z25@R5>\V=;%9==4ZEYD2KE+W!)JQ:T\`4 M'CP@OVNF`&CG`\O4/=+9>,2'@+AW?ES0GIJ]P@UHJ(*6622A9:V"?(`5F;5* M7V34#A^2S:_-MJD+`71&%^B[F/WL<&K85U/%,RHU&]G1Q3KP*2!,"C)4XNPV M+>O0%R'EK$:`(:$B5D5J!M1<2N0Q6K9*#J34Q M+?ZQ52);MA>;4=,Y58$M2I?3""O85`RH-VJ/]0PMV0QT"WM*X3_XMW3K@\$@ M3FI@FA5&B`P00.NVS;45'BT00;VS4(3`QY-LX),_Z]8H'.5BVD>@P,M6^$)-Z<("A1`.04@Z2%\CYG^'6B$ MRI`(3LF!T#KK((>".&LP$!X<4W%E#1O;C##:;'4-"F8$G5M]_6#K4+Z&4_`$ M_.=HD8T:6@Y9!\Q3#]A41FB($[O(LI7@D33_)9@3!9PR,C(RI*B@M#,R,C*\ MN*RP7>@/6,P`5XM\)`CK/8O`<$/AGP*+3"0$5_=,]G0/BO_/.B@H&SL.=?&+ M`;K__OY^`Y=>V.#0@_`"PG$$J0`X@73KYG[WZ(M!_"8CA.1T&JFD.`ZI@''1=BVPD%(7M M="[]@\D<_U]HA!@3\J[WT4F%THOQ=$'[_B4^]A,1.\YV%7T6/74/5E52F7AG M^D>L]U,1BU,$%'O[0KLP==$ILUU;PXO_1`8!"FBX-1<$%`:0D`X(/F4H&#\) MAU1IBHG?W95=WT^+]QD4B@=&.-`BAR@0<*W^4C,"..!UQ(H.,5OJ"K>@9O\W$'1\L2^;>\==-(K"Z;_B MC4?_#(W'HY=V?P56BW2`@\\/1@RH;'_[Q78-QP8`+LC_HL.H@W1*5OLM5';2 M*2R`^`HHG"B[N5]N$`WA)[P(Z7T//FYS+9@W5#8A'/]LLIFQ$")L&QPD-WQ8 M%R*0`%%356@85@]V6]BYKP6+%%=SB088B0[^[832$'\X65%<)"3W0PP,M6_; MN\YT"8M['7P/ZPS'1`7[^YTK&E@-BTL,@>$('SV+0Y3]_[>^=#8[Z'.CQ8L[ MB\B+T2OHP>D"\Z6+RL8-VV\]`_.DBW/,$UX8*_!A_07S]@/(B0Z)$XG9ZW<[ M[W)(!\,66L>\4_81;-6ZW(NTS`Q.TO<3W+8OF/TK^NM:_6<05[_W;9/A*USQ M]W1+9P/P.\>_]C7=_W(_ZRL/O@Y344_[Q_",*VU]9> ME_1E-;8/(.T7W,'R4PP,:LH@*\6)"];>;'-X-AP:%P\6V9'LLA&0`,@O3/A; M^K$!PUF+5,U0+E!14NDM,YL)+7PL`!5G=NW3\VI`(LH4;"$-7PF$GRP8GWP3 MLEPD)4=H6>*N0GD$$(XWZ?P.:-ATP M/X]$M_4\*WFX%/3_`71NW06V!00"3B3O"XD==156!=/]MCXL5!366>W[6[@D_"OK%*@^$*@(;Z%"7;7V%6!&S5_/A^HM.ZZ8]0)IZ MP_;WV!O``T@!7\<%Z'X6=!H(L[D1`?YCT.`))V`\BP(Z`74N"OX"MS%I=NK&101`QUM;H%M"Y8$&G7KP.WPT-JWD&71X$##"T.= M=,_6[2Z5`D)$Z4$PX!,"J'F:K[5F6#-;TLK)'TALH,&`ZXQO@^P@/]?5=
$R##C:P-J]#A4LEG&!7HX!=&7SX`?00"P_\+7QK`2@8]@/0-?F8]?PO\ M?WU?^UYCJ2L+["M:>U!R[EGNLE%\H004_X29]_UHL`^J36P0B+H-"&#=R],V MBU0KP5)!##PX'!"!].=96\">'T!1?/!#A'3<[8VU!GA!#7X_N3PNK_TE_H69 M]_DTB19]#@/1!5_M]L-K&Q;%N(F(`/?I&+7PC1H)A+9J)%A!]32UJS24+V`@'+RQ0#?LK MF_A_'X/`'S5L`3U&%$@-1`+`!3@PT]B4JV6\5Q0#^_:63K@B,P+\MKP MUVP%AUE^"NQF8G-[-WT*9CL5XBIU/V9$#07@^9[+RS%,)`8-WB,I`OMIGJ?: M%0#8!Z'0!AXP3;?K9E<@Z%DF#;F_U`1"'6:#O"2Z?YB+'ALPQ(0D0)$'N`A, MC1JM>(``G?V](^!:$(D53_6)#=S;:Z_K"6^C6QB2%.3X@P=G'AP+Q!Z!XF=S MWRV2`"4$4A@/X;"!=6,:420@'QM3[J5I44!2C"3L@KC@<*L)V@+1@<0DJS]& M3Y_T&P$"_]!H$+`0?)M-K@@$2QR\:`01`&NHAX!Y!-10$;-72.(,+&\?,!N$ MD`$/,"Q\%Y%3,0%6=0Y50_PF3J;!K?CH3$>X+1TNX=*`EU/BCP MJ\$BBS7LE:[T=PF#[@0[\7(52;X(@7P?FQX4<^MH',L4WB@@WR01(.1U$54C MLP799C"`])SJB93!G_<0-\7AW09S#VLJ^?=R\72;P8Q?B=X_!"+-P&Q?)`@) M`+,>F$T;45#T4\PU#8&0T!(/#T++(;!"*`^-+%<-@1:O5+0'%P@TT0<4HW\/ M1,L)-"W&O\8/3%&M^DLA*Z.PRPYX@R\(CPN-2XT4B+_42@W&T@3NT(V$D,,? MMGWLGB8`)\'X$"5W`"^-0O\=)`$*("T?BL&AMW*#5=C!X&V#A?^#9W03B@I" M.-ETT82M47K6X(4'[0O81\/!X_0(Z%)C]8L*O^'!YC/+./BKWS(#^8/Q_^K/ M,\9Y?EN]:KOKG24&=-,OU5UX`56!YD6`W5Y?6YLJ]`U%BT+\.-A&Y^\XFLYL M\-QT)X3'YQ(5W+98NVD&U.N6+;$$_@_.2>"P) MD,C@M"14^$(%Z`^!&]3WV1O)J".6.\X0(\@.HXQK6,M]`D8$G(,/^AJ(-=H3 MG0^?C2?<`Y8=/`\;V,,7V`$6*_G2$(U6%.(8%<[HB_K?R/[AV[9AAGN#C2_( M<`/(9C.?!X4``P$#6@@+>0*0+V=".'EU#%DK-R"$Y,A8,4@Q*I)!N[)BT@$37(A,]W#ZT@8=&)Y7%(3%(^Z1R=.M[$2 MA0`9::O]N>4VZD\$6DQ90(1B9KLZ"'QM0AE+BO5-=`!@_!J^X*Q:VC5=9 M=06+?0AV&_1O!-$#QCO^=@@[^WCZ]\>_%(:1C!08;H/Y"'(I;T,;"B#4:#,Y MQ[H<*VRP4;5R3.`#5==]N%7,@#+SC7@>D`>_Z;IF_#*0!+P#X"/1B@:(![(U MM_V*1@&(1P$%`E8(6<:9*\G8QUS,W2MYEF4L)0$"`J;DZ\XFD"-&(4<_C)JF MZPY?!DP#1#PT@;^F:2PD'+]$CN3!TS1-=X_D!^CH[.Q-TS1-\/#T]/CXX-78 M-/S\C5B:Z;Y#:#?X"<#P@`.,O<+&KZ`110@]R6*=N&"S@0OY$:-]F"$A#0HK MC70Q>\D@O&=\.?Q_)`W]X[R5SF[\=P`U!^^-L#2?DT.(C_DK"#1,U_TB+)`8 M"S@#8+[N5MAM`SIO`TY83U:V)0Q[2TL?HVQ`OMON`N\"*8R0)\J6A+3W-)<<'$W3-$T8&!04$!`T3=,T M#`P("`2Z$Q;2!!\0!1CGEK#I`R@\-9>WM0MAM@2'#X,`"6%@$[C8J`&SR"`3U%P`-G*F)I#(HB!D M_'&V!FW!X=\*^#<+X2Y#H_0'1C,*:ASMWD]7OB;'1?Q3#EVL^-C-]@2<5!RC MZ!LN66RC-(NQ=ZQ,":$2//_[^.UVIQL'5KP$510.NLA\@\Q.D9?<0J)3>#,5#R%X&QL:](7X"+L MFO\^4FR[P4WP^`UA6XOE7?T@NK]@@ST\6`):87P4F*9X_;EA>("%X.^)R^?# MZC%B$C\,/@U,"H&VV4Z>40I04%*EW#O7K]';AV.>CA$!+L%&_&'6[#%P]C%M$,R$*XS5=D%HQ>6>T04JYL8E"D(1*O/?YW#N`;51!7._`/@V#$++#'9#SO#=!XQ4-(LUU2;G`HI2ML?^$^PT6KZ59/;QD0Z!`!% M2%*OI5L+M->H1E"7W M^_L*5Y5MPL2)!LG@7L,_E!_1B+FK*:QP$R@2\3OVMDMTAH],]LET$ET0S#7$ M>VNRO5ZP4(YH$2Y3O^Y2`UTX%@>`^39&J=E&?./=/YR+/BOX*WXTBU8*Q.X@ MT%)\.\!+$KLHL)AW;VF_$,((/+_Q+'P`C9X;!M&5\: M7@N$MRR`><+#[\`:@@B^%8(O\U'$7K&545'K$?V%)P$!EU`@OX66@KW(U&0GRS.,("G3$2 MFBM=CVH4\R[@C_YN$*B"#X08J$`/A<"]%`47&A6H$.+0+7"-I,C')/X&^FZL M@-P,%23O#`*I:"T!WQ1S)H'^:/!B"",+<;,'B'4-57]M=8S0'MX)5@SC]RI> M;$(++8B;88WH0F3A_TD[^XD6B4X$?AAG57*IAJZV'MCM('"(YUFZ-7U3@_W_ M3M7*P?H*X+=O5:25"P6XH.]O]D""%*WQ!"!T#/'2L3Z"7>=!/Q0\%K^R3*[P M-^OI45T>V#O?-\B^AN$*L+[2="5H;HN]J@T:7QL)999>P\K1O."7&C8L%1S; M.\%!5Z:1`484C3R-;^BB(^8#0(EGBDP6!!I]"PNM`4QA+YR> M=`ZZX$+U.]W>`R#[&DTJ,U&'7,,J%9KD6-%54`>N/.#/UN>`0%&L)#0$K(C? M*$=/18O]#X:#VL;_1X\HB\\KS3O+MU[H!WRNQRO%6W*!48Y'#8^Y]FV?Q2SK]8TYE05U M':,9*5L2+#MR[+@6%5IC`WP1YSC-0L(OT!.`?0`:(TYECB5#\0PK+1K8PG(O M:126(=:5.ROQB:-E++@BT_#5$$)55SB$5TK6B_(%[FEU84\W,!"%/X6AQ(Y( M7Q&*`?S76[_I4E4]>,<\870=/'*-/%RK0>!W=`UU*+U/NA:-^`L,&Q#KOK65MQ1%$'4-"0H= M=00,0"=KB@XD]BI!KX50T#W&%Q1,%11HI#A1K9J!(S)MG%D]^]3;\+!]_J%T M%D"C!3`"#S<&B7@,H$`KQQWA;(NC#`@&'&]($--UAC9]]SUP[$T#0$W3-$U: M"AXO%&S8$%8P\0`!#R\[(4\"`P0%!@L'">#`"3P('S5).+#$3YS)._5^S16= M(=R7%U:+`CL9A%@,QT;H?P)_.\Y\[>LSN3R(ZREJ((TT`]Y9Q*!U#1BT;J!] MM@0Q0(LT,DV6_CO];5"V-UV);P0"#$0O!")THP1G1Q!@L1=8%JW_JM4`LC9X M)\T'`@O'`I/`UK;5U[(^O- M^P[I$U=!H_6`2^J`EE*E@:VT`ZCC(.#B2]/+TH`_"G$$)/N(`0>-I;J^`X[W M>S`]X]U"&`WU:HH'/!H./`W[C;N^+H@&1D>.,K5-67,;@'\!/=N^EV`+2<8& M"A6T!PT?=A4>!.H0\A!5;-%0!>-6,)Y2$RC9"^@+4D??7+;@0->+Z`M8TYU0 M@U+!?0'VI3?Z:_WO;JX\GW7K.EJ+"4:(1`L%ZR\[=5O[5NMU#(!\'1P%>^LQ MN!5\%B#E_U+-`-[-=3?%60W MM)<+0(U^^CU$P`1V'P0Z<+5KZ"3_U[\']%:`R&<9$.(8 MP'O@B8S/O_U;]]JIM[NA!LOV"0-]D.7LH=02)]3K&\=%;^O7B@B5$HE-?"T( M'_C?RXM5*HV&=8U-&(V5F'M%%%$'6^V)=1`B.%6OO](O1>D%R/,/G<)*@^,= MB[_T(]=*SE'XB7G\/4?CN?3^EL$\"-;SJXM%$`6G[H"V:(2&N>.P_XWBA0RU M>.3IB(;X\-CO!^D0@<;.@<(G\G+?FB*WC<_#WH#JET`XG'!6W'1J5318-44' M-'M=7[-3P08]_4!LKMOP.37PZQT)BWH-"E'^"^!JC2#JD(:)T`#<`H8."WK! MQ0&&SI5!OW@PZ\"+C@]%!3Z8U2N#?Z/M#9MBJ$*W$*V[`/`_6>YA@;\^Z'5' MB\)H"0/+"/PQ<^"(:2W'!ML!+;;C%4AY2HD&+'&C$M0K!!4I=PSJ]UWT[D5K M%'0-@>L]@^Y;P8T7/7VDBP=_!",N2QVC\(-Z&/_K:HU*'SE[)QAN#`M`BX'P M!NP;,Q>@4NXT_*]T5X:!VQ$OCT)^6-LE'C[VN`L[8G8%!!0+/$+I<@N+G!PZ MZ^O##U`-6_%U,XO160^C^KNYI]JWJ#3!6K] MD`$(.%K`0TL?$U:JK56WUF$?,W3(C`-DX!=P%&X1`_*),(%DP6&BW/Q9/?D% M[^UP&J$5TO@@HP@RP#2UV1"T-0\\P*$5M\]!#"_B)J#DBT$0[\+=6\N%`'G6 MJ1@@"/<:3U.@9>961`1E=!7OMM1I;&Q_4)H:,[ MR)T_%MOP=#)J-88%E"L(#<6B7$\_EK1;LTY34-B M;1&+;<5#6Y`;[>#TXS]:"`S?;OB1*_UH6;:%BPCO\O_G_H6W@`6'T6O^$'WA M;WV[Q%`(:0A&#W3PB\90P>`,-AO=&:-7-B"H1#O'$;2')1K+0%1(*/%2\&G) M!\I^,A7]0RM1X5;:IHE0_,:`O!%^?Y/_QP$/QT'#!4MH'7YWC4YUU3V-A7]? M-]<<3P)S#JV_'@MR]%RWEV@#]B/!B;2(7UXMU?878`HKRXD*BV(K51\PX?&M M$0B)#XV'=0([N/$@-ENQFVTL7A&#P$ MC8$]A3%"++=9/^<(3H_&TTIXXMT1P&V;23=%R1_`H!10J2M<$$(3+W"77:`MC7T@#@` MW_`:%D#;2\0;97-UB@90/(!^E(W^N\'I1@&YOQ5`02?Y.\IS.6BIX2(#,;J) M<5=;55ATS=#9.]H!VSLL$\*(E>P'X%_A]IH#4RP6&:$[Z'*JW7>7),<1:D MMDS/'+W`;T,0M@2V+Q$/(B"T6X@@%(!9#X"449,W7X8O&3Z>$(-?B]4KUXK0 MC=;P','Z##`@+P?1&*/_0"Q'%Y'R._-V&XB'(O#!>`$K\VL#QHD!!MLC;\=A MCVPK?C-51YDK\!O*#]$=NF^HEKC(\2OWJ`-'$%VQG2U% M.Q?3,>*`QD+G'XL$K-"@Z$*%W\3'.\%S#^22`48_`[R&M?4RKMD+T#FLL%$7 MQFUX]@[QT50]UGQ%PFM+/0/V/21K`6%?1<**FW2+^Y)1M:]HHY4/;:X$R9*J M],KV:KAN5'$I.QE]0+I+/Q&+0L@,!I8+O7XI6A3`('1$ZT%"5<+-3GA!/;I* MD`-^8G<7.`!KO$,@M[X6K6.U=QN;%G$K5?(7!`1T4('3'R(YN,Z#V`#<'.N= M,-!?#U[;FTK"1D834'B%ZI:D*D"PRAE21H:&D%V1/2/:`2,/4U:X"*#)`'*- M`!P56')9KS)K4)0$KG@9K`O`0&47[L%6E%'X.$@B"PMX013J-Q4+JQ!'\(I, M,`$O0!.!,);]B`@()-#)/G::96.LV*\(`ABO1D5JDI->1E.K:W#XH-#>R3P] M;#7(\A&:"$8/)2L!6TE.9!@\S1L+36Z4T2O55!B,7/*<^^?XQ:,))Y-"5)S' M9_EPP"B."$8\1GB>P$85V-"4P\;##*0EC3R:RWS(":T#_?-F?2P>W0B&CH`& MHE%!D=@[D$#X2EHN+(%3.@C<0V3$1**A#F\>PS<`V],7+&\)&0*\+L+E5#M MB8"*'T>$VXAX`_#$7Q[6P^$P1"@BY^J0;RA!V`\#X>]/*9K:+=? M7%@6GD0#-"-3')HH)*X9UENX7=T++")(%E-CX#?W]U4S(!BT!NV7VNVP MCQA-TXVB>4K07)9+>"8`MRZ!!F6'G)R\J!#$7J,E^#\V=2"I-/H902A%":VY MR3?"NV0DGSRAX/*`+-7*C=)40)<`T5`!N<(L-+P"8,".QA'">MI);!:HX!98 ML$=)(B`)+2&79B"$9R>796S/O367!#"]>)"16>RI,`A$0-AU@S3W`Q`0=#F< MO`UZU'%D8'L6W%1=7^AA[7TN?.]U*'_KVQI>\ORB\8?>YV*TY%1$`Q#9/HUB:IRB^D:KGI(V>/ZOI!(V"$#QNFP")]S.07#D%NI"J]'N]HZE-$- M_+.\"Q08]M9.A=*30=!F<&RAH8-^"F8"&77P.8L5+E#1^")\.?BS#W4#,0VO M"$`N!B/AE?,L$A/PVD6QA4L59JL+LQ:'9V;$UWL@QL9^V>>$,O6E0F:?[YHB0WKL.`.2/BZ M\E!(0**AE>E0@W/+9)?C@ZZ%6.K(W:WP4+P+)12!YH#8A9S9=FSV#K%<41W4 MR;(LS?9J%O944LPS9WP+;5PM=1.W`;9"!$/D7_;."=K-Q"W#5ME`#5>.,8/(C!U!2[H@,%1@?2(9B>' MO1,CZQLI"`N9M@U'L=?+W\:?"N^55U@'7F"/`D`&1; MJO\C5W1LM-=_!HO."\_A&[M"P_8PF9A255=6]/%WQZYHAW,\5%B+V!*#PS!I M^[MTQ7+[.71^!`-<.#@3?(C?=H@8!NNK%?$0?VR-K&,KZ$#VQ0(=$OU=-KK] M,'69[4A%$,8`,!U<4]0Y-$(.K&3[8:'VZRK)<@>C+>L6$/>\/%@+*^L*`G0- M(,?LJ!.B"BC\*_H$&MA:/QT,C;0R`K:`Y410*2`W,V$61DG>&2V80/>!4%%6 M(RI2B^9RA71X=@0.NB';;!$=.S"C+'>DJ"FWEHB.CGAW+.V@MEW_GP;42%!2 M`1%H!?P@#`0$?H!^(KFV75LDZVE4:.U+&\:6L"UF[&48*K%E$2P"+R=(]1$] MA=[WC!PXO3O0BUYPAQQ25E4MU`:39^MZ47]0:99-LP.)\CQ118K3=,VV6E(3 MQ=0#MJ>??0=-XQH;``4%`04``@4#:[I+;00$-?^W,SNH!S>1#;9*4B<$``$. M/=M]20(#D'@W1U0#7%/M.G.YCU!5\U(#*@M25'1=TYP'!HQ(`VXG/B_[9M=: M`P!7$`$0`A```Q!W>9`W!!`%$`8'"!`)"F#`\O8*"PP$#1`.#[]LC49T"*NF M`W@3M%]MLA$.B`(',P+UJ_A"B1'K+%%0E=K#7UUUH@R)`60,)FH2A(3@"V`` M7E@23?97?B6TQ(:+3`_]0E-M`M6(KR+^2`3V@+?-) M;0;(A9S=05!&0P?C:+#%:L^FP;3)0K:+'$#\GA\VL@V:"$&;42`_J'!E$V9` MH4U`O;^^5PN.O/\%#J,;@H'_!O9HR'UMJ'>`FHDU4`=3J.Q`D"T"A0F8T16M M`[95WNZ"W":HPU]H6"IQMDO#(5Y7`A.A[%C<+3:L!3/_OCH$0%0#\2_$L,'@ M`F8Y/9X;VPTZ(A-T4!1)`I+XIHMM&9`/&_)T(J$`"$0+T:81=!F9-=3:D'.G M1.[!X8;4WL)'E.O./18%`?/N1V`5D#QJ0&A%5]K*29J`X6D8J0H52-GO[=$+`VF0'1"(SR[(SP`0`+2O;LA70NBD'`S#N.$6S=_,Z M=6-%,Z79EAUV9SF!-C(,D+';K0@*`44+??0W*Z2P`Y7R,%J:O4"M"/?9'A1% M88L.AM2]#161\"0/V_Y5M73&0`,S9D^8E;'&`0W/=Z(V?3E6:W4%&_5`*7JT M)J1%%34\;E,,.[M?IZ-UU>/">'Y<#5X*I89Y@SWP":V-I,)L/Z#)9B#^R"*V MQ]@/^D,?^(PHR6:M'?1PIS._[FHFTB@5]B_R&VN7B%$TZTD,5=(&O9(MVQ:3RRRG%.AJ%M;K,(X1]R;;&!,4!BU84'S:`,NH)FM4<-HH/'B_9:6D9UJ MP3L-L!'L"7@!E`^*'M#8W!_@()@L(& M)9PO&(-:4[XD_C,7^C=%*>@[UGT/P>4#=ROJP,F^Q0/N5BGYZPL.`\T[@!<= M^4`^+(N_XK_;OO!R!@Q3M-J7`R"8#(V3HGV?8@OX#)6- M`Q<]VC)5&:#'1RFNUJ'4&32:@'(LZ\:Z45L=F`F*&3@3)+3@!0W/3P81"K31 MF$O&E2VY+$:L0-<+^\`5K`/"2`3!#3VS_%VP?7T5!?];)@6H$?;>6IQ;/6D4 M?`HM&Q6((#$+(H)16@J>RE89"^:%_Y?B#X"X>2T#$5?WZ<'Z%]'M_I.H5?@#B)5&P;[_1_>`,^$!?"R!Z0=`#IYM>9(=`(7B"0CIZWT#1ZJVHR2X MN`=%+L*MZ`BM6U!Y`\$^BMS="]+!ZA_7T*,L(-L/2MUE*]#;UA32#`?`$4S5 M`\KWGXMOM*XHL5IW/D3N[\7M1BV3;K8$0@]\]5N[5;U#E_Q*<14@06<<&`O' M-HLS:5WW\M8B"I19MLT07]&.0F/E'P1$GCF+,EO[N,6SHI'W/"C\J&91FRH+ MP%KCS78/&!AITO#Q;8TG;D'.(`4;%`B:%HW=HE(\N!"^`EXXC$3?#0K#7R1B MX;+)72CK;(4$^T:,O4).:@/Q^XHFC['&/(\Q;AC7ES2]8O&!/:JWJ@8A?@%& MDZ5<=;%AVUXLR+QMH2WU#,.-0P#1USL"#-1>=86*0SE$P(-;Q\'0M]%.0E1( M#9"J`NTE3$\?_J[BFS[*?&"L`H"!5?!B\-"F4)=T'^@@'*J&8`N.%V)1"WA\ M,HQT!@,M?+LCA:$&)!OP)')11T)/5+G!NUL&M2:XN#,[$'1%>/NW+U-!/2#N M#'+Q@_H3U-9BW806W%PI<<3OR6W)V*]8$C2@%M^IU$<=. M.PQ*+[LF&B\NI!,]CL"+\9V[`VY=N8-_4CV0#PV!)S\G/T0]D80V/9.%)S\G M/R@]C8(:/8^&Q#X^/PP]D@NY,XEG5\C4&S<(_].BX0T7;+#8B;_04>T?!29* MV`09I9OP2K2!3)0.K[XJ/"<^PUT%>?E"[X\6_8W;7,$.1!U M]101=`*@PH55H%$J)<)%F.92;T5;1(N$9TH]@2\KP-01BD0*S;2Q5&U4`\_C MHK74)=JX8I4'>?K5IVA;D2\ M20JC!0Z:`#CBXD&B"@H1+X\(45,-&YUH.&9JT%"9S05U_CWC-""@YRKU%X`G MQ`E(T(F3=@CWNX<(]^!77%V;>9)T`^$,@E$+QPC]6`?E-E-20Q2.4%)6:A;. M@C\[2#0(7[Q(U#4=!5Z,\H"'"@)C-'P\JMB&T<<'R=>$^T,3.[N#=`F)=?N_ M1.$-I8`X(G7`@EUO#EYD8M="59:1O]^-=-1,]5@M0-3!6/;]RT%*0-P M\1?K5D\$[+KAW?^/C@-=JDN`^Z-KJ_AVVXI8N$$.=/:L)?>-]P=Q=1[.>`$B M2M#M:J:`[%2\UAZ M=2>!!N5L]FL:)/\'''(`KT7H"BS00<,=&@"S`+A&:<0`;D?[I+:+"%LZ$*%` M2B`3CAT0+6"E]Q`C1+M)/3Q/)6@P`"*WD!'$YH&-AMA$%[@"9@$'[\$\+AJ7 MJR40'9P,Z1\JP(6H/OET$MUO?-@.%W7W".XKQNG1^$#:>FP%X>CT&VH;T:M& M*"0GV3[2A^B,5_+8NW0O&:D)!C93)H%3BYZM$`WL/%S#)"!8+.,-ZEM0$\!H M:&4('@WM9[YT7(H+)XP0E\`-FMP'=?BLPT!L?[Y#+4W&A3$BX>",X"44H5Q3# MX@>L@7KN=0\L;!32N`FSL(&P7SDH5?,[MY%H?C!"/:#O[955?V@B:T0S"(6Q MN1.O\AW=L+](FO.KJID0`79QBMU=6]46?S-WG^"%^ZO`[A^+]=HPBD[=NTFZ`=H(PAO+_BPD-/UBD9J MT]!'@W8%O-#%"%$$ MQL"CQ_"EX5Z!)>_FT0`+(&9N:OC^#C+(A8WP)7"J_11L+',+Q?R*F!,9UJ`. M1L\%7*X@[9X=]1)W)[1<;4@&N!%Q]MT%`[@$"`42"P0T73="]RT>,P,Y/P=D MK-A%;9\!`@,[&$+&D%\$Q.8L+ M`:W@C:!\SFJ@HV;+1KORQ4BK2[R'VN8+!'@$8A/=1*X(8V8L#WS7$-D"7A`0 MWA!&R]P;]FF^Y%ZJRP318G9)'R3=Q3NV)HD*C8@BT!S&0+;2,M*=`%@6>YG" M$QV@1\)RY-G7WNR;*W0K?*CK"DB#&L$#]78(2=[>BNZ`@S2*!XDNJ`@(Q4:U MM@=X20,K*O`?B]8?#+T`+P3UB13!Q(H/B('J^!IT14:F!`05^EI@MZ%DB-M/ MH?74CR@$VHTTVJ14TD/0SMVH@1BX]J:$PT@8`MGKD&Y4W'0BM4CAC:I1 M)4\RZ(IH%-,5;U0+0:C^J5VI'P(F4B]!!`9K<`HH#>PHD6"]P6O[(+&P;H"Z3="CY=B^SN'!;,F>(2!=\ MLZ-U$NW?]HB2+;-]8(+_5`B3&Z/ZZ\-DCP75#(P41;R_0F2@#X%Y!&CW%KZT M9E'L4@PY490%FXH(5C!P4;NH640(]DO;5KQA2P)#^6L,65O"9SQ#[O_,S%9# M,C!80S`P]^KZ!6+O:O$S10CW0.2$T4P4AX)@&N%E:ZU!]P@^(7.B-E/?>PC! M83"QC]#=VM^+1595C6L0J`M=7D$+S!+5O9LS>#PE4U]?VQD:ZQU6#.ZY-FH! MWG7;PF2/_8]5##L(D_C]SC`:BS2/ZZ&XV^LH;'PAT"_-%/>86WLU(\#L,[1LJFB9P)IU; M&LM.#70-NKV2Z1`]UWD+;P'%2+FGI+0,75!:?'CR"5`6N>>^I(Y@+Q'9(KR= M9J6D"[V*':GKC9P+'QVK92^./'8M&S)J`_=OJPJ#E[@2Z3MHH$E\.PYT`]E3 M1#VY!EZ$=J\5XN=,73F+^U;M%8-FHCY!G<6NOA+Z5,M/'\NB$.WB&")H$`>Y MWL7A]. M]>L&@<.A*FC`-!FH/Q"3](AME5DT9*D47$"``KU")(TL!M5J444T2#Y<%@7_ M>@2\T]!.*_#8($8`8$2)VYUH=P;J M`SAU!M."0[$U$V!B(_M<2A:C1O>1[#V>`]FV)GX1`?X#F-Q00)D445,KNF&N M5Q?52RLU+!>V`G,OBAK)&E`#RD(6'M&C_X6BI=`8.LMR!#K*=FFBA'5D:@(\ MI.(V"^2PA@9;3@$UJ(>3(1H/BN9+V"2#41??.>D&P%8)"%B+3M%V83]J"<[7 M1>!1&\G,J"T>D2L$D6,2Z08]W)+,'E50H5:Y:7`%N#DGDD#@J\FO/%!14EY) M)MV`W>\V4$:\%,69&'B@?K+H7JU$9 M/E%2)A8,*S%KFI\J3H`"/!@7NRJ:^*VU/5?'>^*K9WG<",J8[_X'T04Z8)!* M5H0-%*H05#C/5(5OH5Q@S)8G#L$8U/">:*,1"G=43P:!XG0;-!)T6`KP@D?; M+Y=)]S`B$VH$014L1J=I%AU(0SG(@!UU'248]P#HUNHE..3H*\?7P[XG"QB3 M?,F,W]XY$M#`.TS6N(3&P"#<1$F-/+,Q!Z$7XI_8$XO'BU`$!8D71EV%V"A` MDB;OF%AWFIH`4W%X)P6I3M9@ASWK9T9!49*]`P'"3B0SW26^=9_C MZGT"]]X6M0BO4;'1=B#0)K`9L`!CL4<Z4E:MU@R* MV%?WJA"U$;>H!`0XQR&%SD%W>!V+1G<6VG@H5*!G/"O&BH5S#>^CTA40D<(2 M$*@U=]DC7Q$0)F#C,1`QBQ+)@GY[K33L+1=6A=)3"PP7VK1TV!!!D4$D12M@ M]C(O>X0>U$1K]N%"#QRUZC-O9QXA&9Z7I(;);7B7X*VI?#X/-__AT MM_'!_[DML^`!.T2-D$RTX&?G+K5][$4U5/,786[E]@7P/@E56_[.#D5OG4AMQ()%F;N%@Q0F0H%]>L$G!%V6$C] M,$F@JG6U+)__'IRP03#GFYV:5\(N=,,$_7W"=#``P]T5%L)03S_LT#1R"3K6 M#(W1+BG@!DXG4,PHJ`:0(!426$9`RIM_K\)5`[__M>"=?HD*W!1]"K@4X1JJ MFET%.@!ZW*.]=GODM-43:A1*'6^DC^PF'@]J&D:A#[$??1!ON;;K!1!T0#3@ MB0P0)W3Y!'?;1.M\ZIZZ6![&&F";!=D&\?@$]]OA!CL&QP*'-"!`@?JX+,3= MD&A\T2-J*9R@Y*XN%[!*!8][?,,K>@`,:=W4I`?`;DZ]$1SIOE*)0<4,=!EJ M:Q5;R0A1"MH#&!T%>4%((IPWR"0$Q#K#1C^]H7W MT0[GQ8!U%01`=0R!/:C;!1?EQN`;"%0:BT:+AH+!^L;WRQ^<6^@12'+MK#F8 MP.L`!GFP$@E`ZPB``'^K91L0\_@P#X?!`KC;SE]'F""!6D`.ZQ.[AX[1!P$, MNW8%NS"O#3)1Z.(]1>\-V])_$C0[;SQK<.V]!"0_-FJV51@#%;`]1'1`6K,\ M9QL".044V+[-]J*6H4N]`QH>/)NA6`;A&` M".L+V$6]UPP7#$UI;"$G/=5QU!Z&&*1H2#$+1QPR013H*$&'@VR(%C!3DM@A M&=A#B"**"\\U,6- M/XH=6Q%M5I4\`+Y4G*0&=2I],!IU(SNY0337ZGOL%$%1I!8VZQ!T*2P(0R79 M*+H%WU9F%JX(]0N-K:A`*U-`5V]&K8#)O8LGVTJ(WHDUKSH:/[%INHU^T$,# M2E'Q@#)D4Q9C`0\"A)"B0P.0[Y:BI1:^\E;QM`H#.4`\;SA2="CDUQQ0%1F@ MA7L,0BV!QH`%%7.?1CGJ0/YQHXIV$544+ MEPT]%S$R;(R8;!`R.@P<6@*#PVR"/9,*DL4?[Y]X8.&!B-_)K68^9E"LVA>_ M_P!W1%/^)@!'T*9<6$,=KLAL*)BY*QA6X2HV:""N*;G2L&A_ED9E<-8$I`V# M*OSM0G1V]'J MT=@+J/3W\]5DOO`$&7*(]XK1<@X[4+2[[R=W"'('.RMV`4Y,=QA!+Z];PA"C M4RKN\&:S;E!N-P7V#F.WP@OK4&X0115N!NLV0\@4D000:PPZ`Y%I#@^[&X`V MT[E,!PB]VE&]@5UXV@!\?VU1'YZ+@SU0`7Z3:JUE.FX8!U`I?<5ZU`8YHA4" MR0_:GRJP0TK[EP-'Z\\G%13ZVB5'T2W?P/9*-/PKT2,2\O*#F44IVY*PW6'7Q;BAH^&5[5Z5E--=+49 M0!M6Q@-"<$;0C5R+R^LA*7O6Q-N(BTET)9(I'W7K+;M9X5\=48/C`_$@'2]+ M%\2IPW7STTKY9Y:>@PTZ+HH1VN9.NCKN;!@N^BI.09&"6+=!1@K:8Z^Z!D>6 MY>06@\;>+!YT#!"W!3)?QCGK&$6DZ6)<"0X`$K1"S*A32%6&PK#=[XD'7W7X ML'6%HY\>$"R@G_,%:&8+^_\O-\H2S(`&D@=;(S9@DB\W*88%EBA+DS8<.7F, MT5:0"0ME`M;JI0:`3E'^9I8U!&'VS81`.\5RVTBTL+DH!7490W8U%Z(!WLIW M3.A2G2HF9';_;4B3VE<:9%Q,?[>(LRIP$&R%'FU,./]#"&JZA`L?2$2M.,O8 M'*%&5%+P>&<+8D<2)/<^4+DM81%1]HU&8((W"7@0,\!L@Q7]>@ZX229K"1M: M"A`/K`MVIR12R&JBAP"BPO\A=7^-%#`[U7<>@K_Q!ZT. MH15K4Q'0#(H#3%NKUP)3HQ]0WY:#`S!XU8*XR(%C"/XPI+(/;R(D0 M+"O`:2Y$TCV>V%I25LFQLU*)4%=1,"*@W2GH=2*MRAE56M66I&2`SWUF!=H0 M4`>#"83M=#Q-+TPE5IL,,,)#&PP4'8*X*1X8QIC&9@^V,(+VYFA99K,$I6RI MV(H_'HI*`4+909$Y^+?9&M4("\$[\'0R%=>Z7?4M_SQT*D1"*T;ZVZ1B=;N^ M(P^5P4DCRE6X1[40$03?-YDK[@4>7A];(,/4<0D17U?+/V1`CVBWP($D6M9@ M)QFFG&@2/8O'H,KW+(AEH*\/K^-TM*\@QA%:;<:MP^>RY@6^BQVR2FS5CW<> M=T([-4AW*"CHI6".!\HJ=@C-8T"WSE&+Z>"KB\VJ-4@139LMG`@A=*6BK!\1 M&ZI%'P>=24&"2+0%+%P/L=)B#C4-C;-[F$OHEOS;[@$\A"Q(G8P?MPY M2`5W6U,,$54S[2M1,P+`/G?+X3XZ`<"<=\J2(IVSNH&N`553`?C/9J)4P,D: M$0(/6Y(ZIA3\7(R@!>`:]E]O`9J(CJ>.:+G71&"H@DG;X(-?X7A+-GY"'`<-]/YF'@DN(4P^\7ECVU?;WW1OM`TWB%5\I[!`SOAM9 MV`1:4B(M%_-`,2%_8"8"#X(S$%'L[1R$/L$!*W<5KQVE*A@ M/TG;D7\,N5>O61@#6Z!H(!1M(Y%>;EE_^U6`&&8Z=0DNQJ!U]/?A@U,%'@A& M2[./P@,)$-.>\8`%0\SO5G-@GVX7&.!4!G1$^(K!UPD3:D+ M+02%`1=S["O7Q$*%K6T,B\OE0/VP\@G"]%&AL$?%-")(M>.FD\=U(X424'0@ M)A5\5__61HXZJ4Z6L`4J_7"B7G0O!7'I!G`1#8Y27H\^U2R:(-8N$X<`(-5F M>BA#-M\-*O3%B2Z65Z8:Y!*&M=Y8(DNI3J?88P(^?#%<"7AQ=#K1$YLC'7S- M)W0E3R105',7@E?*M"'&/MD'+2&5@,!7%!M6;1@G$E$X.W'V>#'^2>;I@)9$ MT#U%&1/((3(?B)&@UWTCGY"8D1P'L!/<`[P``V@`D1^(D19"#H"(D3\T3=<- M?P9L`V1<5`R@3=-,1#R1'_>-$`()P/"@`X`,H$VLP)$?CY"''""3T)(HDJ!= M]SLLD#@+6`.`DA#(*PP?(),W6"CD()-;U']-TS1=W`/D[/3\!`@P@'8>%Y,? M-EUW0A\P!3@#2%R3:RHP@!__[Y$&1E3Q3[]:2Z=34$V-_UAX"):*V@N_.[#_ M8[DN"_Q_"0J*)TBM0A(.9DP0]NYX'[QGTL03$6/.0!4PNA0%AG+5RT M7`%!9S<5,*,S!MW#>K`5@W3=2A"X$73@DG3=$F7=$:JQSX0#'%"L4L"RIGL& M4-*%'&@=B%/U^>`2_041VX$[225!H;A2'M"="WJP(4U)(A."V`P+ M:GP'9+"S!Z`E'L`5N`3<"14&PP]+:FD(W%9W(!<*'(+V[%I9IT4'.,1P+0.& M@(,>M4[30M">@K]1+5\=F#,(2-(V+%@`LQ0T(&T,&FU%)$PY++/)!C&`MTQ5 MQQJ8BO2D/HT4!`L8P#]2.19S`2T>5]],,CQ@]@6][V40/)B=52)1VYWA?>A) M$/?%W71)LQ21[>VJ)`"/MS>[)`#N$KI2-5`1FQN%0?=B;N&"49/ELH"WH`PV M4:P@A#5%H6H$=59*W,60D<&:1%`,H&Y9=4((8X<4\';25[&-2O]B^<`MN(9)9/,, M4BO*@`#;&IG",@``KD6;H?]!-A0#_?+V?0`&`@$'$``#!@(0!$7^5^JS``4U M,%,@("@X4%@'N];]K9(W,#!74``@'%0<+_7.N M`!H!#@`H`&X,`"?TQ[IL`2EK*&YU;&PI$%-_\___=6Y-;VY4=6579614:'5& M0IS=&0UVUK[[7!U M%PO6`;)?,3GW M;W!E8-ONYE@QZ[/4QI8K1R>2<*+18`9]O# M10XA$5#4.KDV[-;*+@``/.7@)?QE];8L:VQW;CY(1V5T3&&Q"W=L.D$*=F50 MMG5P$_^M;6 M[`WL;$`0!P8`@4K@MT]T`1>;$B9SVY`"7^`GY,K.+@#_%"=`E(W-#A#3(Q8G MV_]_R,`A#`D""+6'`2N?)C1^Y"4M0RWB\H82#"@``";!PX`=`2\%,.@B0I8H M_Q]`M$`X?3!0:!@+[=_:__]"H_@D(05(V&O1$`YT#FH0:/!_J?Z$%PK_]E_W MO(PUH1M>PVH!6`3_%Z(&^=J-V[:UVT44!1!0IP+^[4X%#'$FT+M]_Y+"CB:%PC M(,U]M_)%R6A82E#G\F^VSIEX-Q\45\SHOO___V__N+N%AO\E&D3\#KN($YW" M]\\N-^BG%@-3Z_(Y7_C__SUC5SEW^X>U0TAJ`^L$5U>F:$@1+R\V5?#GP?__ M__`[]P^$:`*]X$+[[KN_0*](55"#%'J+'60?_[^P0#33ELXBN*Y5&53'@8X4 MR\_____VMOLL5_)62_3H.^\OQ@ZM,QDDP!3<5>5R.Q==_.#_"_\B'?(!BUPS M=%A4D"WX%(E!`^_=[:;B_W^I8]5)U8L,,_:`H#C?N_]M2(`&____C;*^0/\A M*`^.%T#&_]_^_6ICF5V-CAOW_3+_-Z+^5!_____W2`I#13$>_LZ0Y6'$@XW1CV?WNW M;:M925%KC7X!Z08#[?___T6+[BOOCO;K&C!)AT.+O-\0,-Z[V%!72T.`9/K_ M____*QPA4W;WZVF`('4Q-E2%W(P<(#(<=2R#O&S#4$\\4#/_____+#,;C`A;C0=MKUI"'!IP.CN(O[_`QM9-U#O=@&;1B`PHQ1%(%W)/0O_MR@W M4WQ;1C08M`ON2``YCT3\_Q!.S_RC^MU6:(":`XL9P&VCV?___\9X5HWX5V96 M`JQD.F"LZ\BT<=9;XS/:3I5]#/__QO]9':;_A6=O^WXL.E_RM,`;@%D(](4# M^UE]#____^UHL!(=]WS96_WL+[?."&\$N!S,ZXR-A>1V;ZZQ^!>"^)G_O00M MAD,`J=D-[5___YN`:^AU!Z;V!\"WT`MEKW<;\ MC/+=QUKD)^/]"-LI#+[H50R*C#T17(7___]\H?U8!H@,$T.#8Q4C@#@J'VO[ M+0JI,4O^G$L%-/Y)3?2+36;9\\,'__^-_^QTIB(LAC?;;I_L@V4T*_A%!:QF M&.\P2OO"_____ST,P@/V";,6DHOX62:&S98-=[#D5U8.!"!6$L+L6ZMN^___ M__Y<]%8#P4K0`F^W[C_\1BLI`]@7\$@Y)MW;;^!]6__"!D`I+,OJ1SM]]/PR M@O]?^MR5&V?"KCT3W;8X%,I!L=I![CQ^9FP-^^^\?_K M<6C(%/-<:,29D)\`1VC`]@?Y,FB\______@=:+BPG?"9]0A6;UG^P_WH%G@: MB^0-OZZ]_'6!"-PN__]+!#/2EXO8HYVLM,)7B`]J9!'C`K\0_/\'N@?F:.`J M:KT_MO%9^S0+&QE7Z_C_E_[E^M`;?QU_GT%U*:'<0ML%!3@=,/"6>___%R!O M+(6X!F>)+2AG-_S;0\8%%`'K_?___R)310;*64!3VMKL8#]T"Q8)PN5N@W1P M?M8,:M`U&/]_@2^%LQER>Q?6K:;KV*TD6ZZ)7&J;QF]0_?^>C5N`K!.)P(O% M1-@N\,8\9$S^____A=1!O#A;*POQ!$LIA`=).'&[W#>*Z<0#0AA%#8D=Q?__ M_[=\8V]]U4K30S___^%@&BU'"CF>QT$S1PX#^"D`7<(UPP+=Q3-/;3_ M?^N/YE\XF2H4;9R0G`1E,PPP/KT9C,.!____@#TXZW0*F6NSK_'K[6<2`08A MHV`M`E@C;"__T@M\C]*&:Z8;GQ,4&AYI604/"8HWN/T-!3MIO@Z%7U:-^PC9 M____!K]>6#S;)<[8,NQ0T+C7C=31:T`'(3DOB=W_A:C__[MOT7X\OKP27D;\ M=!^-3=Q1-_C__U`F1;9^@=O<.S5_$!'@.TWP?_0>MQ_=*?\"___LB0G_+X/] M'?P[TNS$8SY\Q0A]Z*$//<[_;_S_B!!-`0)\*\PZ&E?*`@I\RB9/!UO)8P'% M7##_____6YM93+U$?]!!30,'\\S M(-3`N^^+\W=[2)0$K'X:ZHO++-N?1&D8.4;P__\O`:3_3`]U=/0=B>ZB=#A< MQH2`A?'`_O___S`)F_\VG&'66KP/=R>-->UD&YR!'D([CWR'_AB"8V7?_O\% M`PD_`4+GL.R=/31;`[57RQ5Z"U@)>12DP+_$(&C%[N.1W_ M____/!=:F$/:=1@8R.^3;"/T%$T2%R")5V[WGAV(4EVA/+______ZRXTB%7D M7O$\UJ%F'MJ=<0L5:D_@$7HUQAL=]E&KDJY^Z?__=KA04A1!40+JY:+%,C4: M975"P1'\-\U4A/#__Q<2,"N[%YF-=U8OR52)C(M7EC!.JM0GM;_]_V^TB[)T M_EFB#&Z'E(E0X=P0&7CT%^Y6:O#_V__"#.`M7FRS8ZV1)'7XT*PQ&XMOL$1; M4_____]70KPPJZ];,JL_M!IHTE!M8/;NK2`,\%90!(E=K%!O)___QO\TW.Y0 M==AF6]P%!AA>@O!T5LF_95=[!]:O#O____^V'8)J")73CC6`M5<7$0-G@SV4 M!;APJG0'Z0&:"J8@YO_____(\XV#"^"Z6E-Y]&K+VZE"#]QH<-+KX$ZK$>K> MZP#)HY:3?PAE"C:\"-C())Z#4H+_/\;@N5?3=Q*3O;OG@:RN#PPP,XZ'" M7O9T=*P'+?[__[3D#`^X(NAA+FD@R'*QV_#O*E-(5DA7.___E_@;4RT1!/0- M$IB@E:IWJ'1KJ\$J%A%/?;7__V_\=2@"FZ6&H_%J`A_4>I,25"T)-4IP:Y\J M.5W_"VS_K8`3;W^RL:S=C021.L?(1/$E*Q> MO:/4RX7>X@4XD6*W"ML.%_7V+_3_YC5J$J7.GKT="A!3V@_K6A@5WOT`P/]+ MT2E1A>L3HF:<%MG3!3.,5!;UQ;X4L'5W2D#COP)0%F(X/\7 M,0O:?/SHV0#N&^\2&_$^)]W_\G_9V?(;\RGT&S?UG9WV;_=H=_AA,RP" M-O_[^7+Z9?L]<_PM_7CE_F/___\M0$.SL2.79P%#`D,;`Q3/4Y>:!&DN!4/2 M^,7_!?X"E`R%0@BRUL+YR1NX%$1`#5/__Q>X\L#:2&D%#G+^A+R""=QX@"@, MJ%/A;[W5X@:!541/IL<4"/T-_@LJL(NW!`BLXA]$S-:X1@@-____"]K86D7$ M,_24_]M<&Z:@YE>`+L^UN5"!;I`\7_HO_5:]1Y@BOM3'_!D,HQR)UKU#DR,) M_[_Q_P\DG%Q7L_%3E-#68!)[V9GI7J`)I"#KW:KIXB]!_['2L@^HV%,)@E%& M-O>FR=!?Z(WE;"@%O-AN1D9<6`DJ\4N2(P!CO^]DD^@)^O\++02%`1=SW3=Z M^XT,_YN@)8PBBTU42IF2-8ISE$EHC5E0!O_/^%UYMDZO"G0PAE;,BO]7__W7R%K;?3[9U!!(* M/"!W!@WK\+G;FNUV:*#___^D4D4$]A`!(-@1[4*GU"7MC[@*PSRP<2X:%G^+ MMZ]S$,_?$3M,F%"=4H(;_/_Y7JJA#7P)G(A049)\*;VP_O]_H=:+58A40/5@ M9V&I@T#.\'H-,??M#?W__SL@6YD@#X9F&8\$863A\9"0^SPPQ?;___\]G\EU MGP/N%UO2D%M8@8$`F0\-@XQ\"T]T%``S0X/___]@`/\HH=91,J]'`RD%2"0` M!*BA&%6[//^52_#_?V\C0V%B:6YE=%=#;&%SMO*_;=L*P`\QEO\`LEA;#X71TC;]JRQ"\#__WE3 M97)V`@M%;E5L0U-ON^W_`W>U\0+P87)E7!$6`%YB,$$/ M]L/NGM'[_R_]5&@:9$EDI:IFVTUU`W@A._W8[3M%#E.TP']I>W`53;5UP__/ M@FTG4W1A.X#_6TAP26YF;Q#9WEK[1D5=V_^_\80-4F7W5;T!F*GV5P>-M[8;)LO]?]O*=O#:]88 MZ!027V/SMKMMIP)L9J-^X7_A7W,)]&WVVK^U"C!?88Y?='EM#QK]_YN?L/9? M9FW`"S5M#0ORVX4":H[?Z-;?#V1I=@[0M=)G$(K&7ZU\_]O__VZA355T$!QG M&(4VV`V!HW'#71N:X;= M:6UN_____W-R/@8*;6C6QA9B(B5N!V-Q!UXL67EP>24-%;="[/;5_U_@_R%O M:5W+;%]H++3NVG(S'W#V!&91-=DL+HT%_O_S@!((PH0(#N3^_H@J=^O53OMO M&___MRL4'L10>]<:86<-V82H^M-UOCY86+_Q+_!(QG-5[LE)QIC[\&>E<^A' M03[?6/C_9>\P&S"U8U.MF[G=5*YL53]$/7^)_@]FL M=VF'#D&QV*PM\0XC[T7B+VWU.8(055XFX:]?11%L4NW__U_TESV:#DR99T&+ M!-$.2U@!%%+` M\U^>U8QE4OQ3_$]014P!!#RB:OO/`#B_U?\_"!BS+$+0)!`PLV#+S0L" M!#,'(U[H_^S,+7L?%`DT$`>_M`T&2GA_JUM\C,CM58`A5QR#?5U7+GF#;[7P M=.L6D)];C<2:`F#IO_#_?QLLLI5AVPS4'"=S][H+0`(N)LO7`<^>DO[?;O&S M)Q[`NBC,296]9_L`"`@^X.V`GZ_!';Y8/6$'=HG%+\D,=2!!!)"PD!Q,U;<(OGR!_0#S5M$! MC13O"D#<2?QV#VB4277WZ08@MA*B`)!B;D4O@`0'TG?QN'7?W?GI3!9>B?>Y M1:F**2SH^`:E7CEW]X#@(XL'BE_[[__?>L'H",'`$(;$*?B`Z^@!\#L%B=CB MV?_>?C-%YR,)P'0\BR>-A#!UW;;=!*P7)K#YUI!!88BQ`,`%%GP5$@UD$U`"MZ9AN#`@&R M="MEVE:P;!535`=R"9IH!060T(E/`J1:(()!A`KMEPYH1'`Z+R]W``2#<+^U M^:)Y+F-O;:$L<#L&GZA<4B!-#75<8%!B5L?H9MN6:-M<"G,)=2[N92LNE?C# M6%!23T9X'T58HL3[UP,60T]-`%%HA4^X78134R-A8T!C.EQ6=Z';X&-Y8_UD M"&]INS!;L`M%Y.G)<#\]X+]S9,``Q7P[+;K!HL0U'#W3[ M%JTYB&4.SY]UV%G[]D-90^)$7$8ME0(`%[6(A`Q2C,A>PM]`@241'7T6X4?N^5T%"`S0$&B!&TH.)5D1^%[Q(0+?V M%OI/($A/+0JQ&B]M.KM%H;<\B3X*4E_E5&\,,5Z:/T1!5$$*(`I3=>S7+G5C M"PH#+KY523Y+J,+)-H%D#0IBS5'B8UOZ-@`@8VV[V4=[PSID>6%HS&H*>[?M MA476=R!P2G3=(&8E(K9U-B!?(&!U!.L*A4BP,`=-$H5"H41Y("@0%0I%:RK[ M`T]6(FZM(!K]87KU)QNEUOA)(&AA0`\/HFBMX?X:E$EW96(Z*0AV`6L1Y6HL M9B`K-$$20U':6MM:(D9K!,]Q`X#!\H`=L M`X!P,A00"U-<6Z#DKC=04U0_1`BV%R40[)-0(QO8A+(7#X,-TGVS%@,"`P<$ M-$W3-!@%#08)R"!-TP<,"`F]@`PV"AL+5QMLL.\[!P]7$!,1`S;(%Z02%R$U M#]@@@PQ!0U`S8(,--E(74P=77],--MA9>VP7;:L@]X(T37`<"'X--,]@@A(^1*9X,-L@@H:1OIS#88(.WG\X?U[:JDX,+&`<%`PM`!NE. M'0L$E@9DD&:-"(Z/0`9D0)"1;D`&9)*3`^/F^V&0!XSO`@0(&*2J9P?[8()Y M@B$GIM\'H:7-]_.QNX&?X/Q^@/POJ,$Y.X3QH]JC(&^!_@=`08;`!K4O0:^0 M_[NV7\^BY*(:`.6BZ*);?J');W>?_E$%`]I>VE]?VFK:,AZ3VU_3V-[@^3DQ M?O=W'-@?!"`%DQDG`K,PHT!FV70C!`<)V*(*FJ9IFK00B!%8$FR:IFDT$P@8 MT*'3-$VS&:@:&P'>31-LVSPH'K@_-Q2`$W3_\S`@7)9P&\' M`0&]$'*%+%,"`0+"1E7(`@,#2/DB<(U`ZF3*3)/R00$H2!X`F2!(`!`F9`"9 MA!"!9`AD0`$0"&1`!H("!(!T6#L@3TVW?"!/'@`[`UIX-DW3-)>UU/,1`6?9 MIEDP3FT!-P,G!HDZLW<#:UUWFJ[JT_(K+P--"*_/-&PZ+NM[`!!"``8!(2.H M`BJ005$U!(Q;I-L7(+CP`4C`1G)E90E7ELU`]')I=&7K%%)D:F^WSPE,0TT? M4W0:;F=!#83]]R*_"U1Y<&57';O9+\M74T5N9$]F.2M69=W<)JARXT5X.@1P M8;,D0+`<18`V@IK=NG,:4RYE<(G>Y>Q6G!9O>99#871)-YL0BF$!%V6])12Y M/(Q*/HL$]:!D+D1!;&RVAZ+7.D-C6GME!P0[H/5R;3,:>[>ST7ES96T=#DRA M:.:"UPW*+R1!+9P1F-N"`ZOO4?1)PH1?HLM&]A4;Y@5GPZO=9\-A&]M;?%,0TH5OF$)=])I9&5# M:!I_-T&P-4V#0GET2FQU<^$9W+]H0$)U9F8I4'DTPA(*`_\V\#D@3%A?PE9A MPLP%035UVU@0+%=75K%[LV2/80Q;2X5N:(+@4$=E+55N:#LL;,2")'A,<)X> MX07UGAEW'@_+F/='8U`V[CW6Q@I! M"P=/14T)QL0<16RF/\6`A`3699E670#%W,$`2F`930);">`*?D$`)(B4H@] MP)-/`>A@-:``)CN1%&PP`0P#;0"D`&P@+^^KP`H@`)0A`8K;F4YA`"YTD0=P MAY"[9,L&B,2:]BYRLT-'!)$`/OL>20%\(XQ$0"Z:IKG%)B?X:[!&D+-"5$HC M*"MIMM@L!_LG"-8T@-I^&\0B`QV#````````$@#_`````&"^%>!``(V^ZR__ M_U>#S?_K$)"0D)"0D(H&1H@'1P';=0>+'H/N_!';+'H/N M_!';$<`!VW/O=0F+'H/N_!';<^0QR8/H`W(-P>`(B@9&@_#_='2)Q0';=0>+ M'H/N_!';$@^[\$=L1R0';<^]U"8L> M@^[\$=MSY(/!`H']`//__X/1`8T4+X/]_'8/B@)"B`='277WZ6/___^0BP*# MP@2)!X/'!(/I!'?Q`<_I3/___UZ)][FZ`0``B@='+.@\`7?W@#\!=?*+!XI? M!&;!Z`C!P!"&Q"GX@.OH`?")!X/'!8G8XMF-O@`@`0"+!PG`=$6+7P2-A#`` M0`$``?-0@\<(_Y9D0`$`E8H'1PC`=-R)^7D'#[<'1U!'N5=(\JY5_Y9H0`$` M"0```%-H96QL17AE8W5T94$````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` I``````````````````````````````````````````````````````"Y end _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 08:56:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25725 for ; Mon, 28 Jan 2002 08:56:50 -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 IAA11109; Mon, 28 Jan 2002 08:54: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 IAA11072 for ; Mon, 28 Jan 2002 08:54:56 -0500 (EST) Received: from mailrelay.sony.de (kramer.fb.sony.de [192.109.206.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25674 for ; Mon, 28 Jan 2002 08:54:52 -0500 (EST) Received: from blackbox.fb.sony.de (thanks for all the fish) by mailrelay.sony.de (8.8.8/8.8.5) with ESMTP id OAA15476 for ; Mon, 28 Jan 2002 14:54:23 +0100 Received: by blackbox.fb.sony.de with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jan 2002 14:54:23 +0100 Message-ID: From: System Attendant To: "'mmusic@ietf.org'" Date: Mon, 28 Jan 2002 14:52:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [MMUSIC] ScanMail Message: To Recipient virus found or matched file blocki ng setting. 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 ScanMail for Microsoft Exchange has taken action on the message, please refer to the contents of this message for further details. Sender = chenshx@mail.datang.com Recipient(s) = mmusic@ietf.org Subject = [MMUSIC] new photos from my party! Scanning Time = 01/28/2002 14:52:40 Engine/Pattern = 5.630-1025/207 Action on message: The attachment www.myparty.yahoo.com matched file blocking settings. ScanMail has taken the Moved action. The attachment was moved to C:\Program Files\Trend\Smex\Alert\www.myparty.yahoo3c5557a87a.com_. Warning to recipient. ScanMail has detected a virus. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 09:04: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 JAA26069 for ; Mon, 28 Jan 2002 09:04: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 JAA12381; Mon, 28 Jan 2002 09:03:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA12352 for ; Mon, 28 Jan 2002 09:03:39 -0500 (EST) Received: from inet11.jrc.co.jp (inet11.jrc.co.jp [203.180.124.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26045 for ; Mon, 28 Jan 2002 09:03:35 -0500 (EST) From: Postmaster@JRC.Co.Jp Received: from gate1 by inet11.jrc.co.jp (8.9.3/3.7W) id XAA29297; Mon, 28 Jan 2002 23:03:31 +0900 (JST) Received: from jrcgw1 ([10.8.1.31]) by gate1.noc.jrc.co.jp; Mon, 28 Jan 2002 23:03:21 +0000 (JST) Received: from localhost by jrcgw1.noc.jrc.co.jp (8.9.3/3.7WSaTaMa99081014) id XAA13320; Mon, 28 Jan 2002 23:03:21 +0900 (JST) Date: Mon, 28 Jan 2002 23:03:21 +0900 (JST) Message-Id: <200201281403.XAA13320@jrcgw1.noc.jrc.co.jp> To: mmusic@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Virus Alert 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 Our virus check system has detected a virus WORM_MYPARTY.A in your mail traffic on 01/28/2002 23:03:12+09:00. (Attachment file is removed for safe) _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 12:17: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 MAA02972 for ; Mon, 28 Jan 2002 12:17: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 MAA24385; Mon, 28 Jan 2002 12:17: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 MAA24351 for ; Mon, 28 Jan 2002 12:17:32 -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 MAA02948 for ; Mon, 28 Jan 2002 12:17:05 -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 g0SHH4h11173; Mon, 28 Jan 2002 11:17:04 -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 g0SHH3u08932; Mon, 28 Jan 2002 11:17:03 -0600 (CST) Received: from lmf.ericsson.se (rmt160220.am.ericsson.se [138.85.160.220]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA13236; Mon, 28 Jan 2002 11:16:59 -0600 (CST) Message-ID: <3C558E9E.A8AE4BE4@lmf.ericsson.se> Date: Mon, 28 Jan 2002 19:47:10 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Laurent.Thiebaut@alcatel.fr CC: Seancolson@yahoo.com, Gonzalo.camarillo@ericsson.com, mmusic@ietf.org, ipng@sunroof.eng.sun.com References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Re: Last Call: Support for IPv6 in SDP 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 Content-Transfer-Encoding: 7bit Hi, the draft allow to express an IPv6 address in SDP. Then, what you want to do with that, it's up to you. If you want to offer either an IPv6 address "OR" an IPv4 address for the media flow, I would use two m lines (one IPv4 and the other IPv6) grouped using FID. Regards, Gonzalo Laurent.Thiebaut@alcatel.fr wrote: > > May be I have missed something, but does the proposal allow a DSTM node to > propose an IPV4 and an IPV6 @ for the "Connection data" address? Another > way of expressing my question, does the proposal cope with a host offering > to its peer to dialog either in IPV4 or in IPV6 for the exchange of the > media content? > Thanks in advance for the clarification > Best regards > Laurent T. > --------------------------------------------------------------------------- > V Laurent Thiebaut tel: +33 (0)1 3077 0645 > A L C A T E L e.mail:laurent.thiebaut@alcatel.fr > --------------------------------------------------------------------------- > > The IESG on 25/01/2002 23:16:05 > > Please respond to iesg@ietf.org > > > > To: IETF-Announce: ; > > cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com(bcc: > Laurent THIEBAUT/FR/ALCATEL) > > > > Subject: Last Call: Support for IPv6 in SDP to Proposed > Standard > > > The IESG has received a request from the Multiparty Multimedia Session > Control Working Group to consider Support for IPv6 in SDP > as a Proposed Standard. > > 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 February 8, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-ipv6-01.txt > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- 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 Mon Jan 28 13:23: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 NAA05041 for ; Mon, 28 Jan 2002 13:23: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 NAA27749; Mon, 28 Jan 2002 13:22: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 NAA27716 for ; Mon, 28 Jan 2002 13:22:12 -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 NAA04976 for ; Mon, 28 Jan 2002 13:22:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13879; Mon, 28 Jan 2002 10:22:07 -0800 (PST) Received: from moe (vpn-129-150-5-139.EBay.Sun.COM [129.150.5.139]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16832; Mon, 28 Jan 2002 10:22:06 -0800 (PST) Date: Mon, 28 Jan 2002 10:22:21 -0800 Subject: Re: [MMUSIC] Mixing aggregate and non-aggregate control (long) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: mmusic@ietf.org To: Magnus Westerlund From: Jonathan Sergent In-Reply-To: <3C551C14.68F2EB5F@era.ericsson.se> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 On Monday, January 28, 2002, at 01:38 AM, Magnus Westerlund wrote: (scenario #2) >> The question is what the >> second PLAY request should do. My interpretation of the RFC, as >> currently written, is that this play should be queued, so that the >> result is that the server streams the first ten seconds of the audio, >> immediately transitions, and then streams the first ten seconds of the >> video. > > I don't agree on that interpretation. If you compare this with true > non-aggregated, i.e. separate rtsp sessions, the second play would be > done > immediately and not queued as it is on another media. However, these requests are all in the same RTSP session. I don't think the RFC actually answers my question #3. Can you point me to a section in the RFC to back up your interpretation? Or can we agree that it is not specified? [...] >> (3) Should there be a queue for each URL used with PLAY, or one >> queue for each RTSP session? If the queue is per-URL instead of >> per-session, then it is unclear what do do if the client PAUSEs >> a different URL than it PLAYed. [...] (Scenario #4) >> I see similar options to scenario #3. >> i. Play the first ten seconds of the audio, then immediately >> transition >> to the video. The video plays for the range "npt=10-". >> ii. Play the first ten seconds of the audio, then immediately >> transition >> to the video. The video plays for the range "npt=0-". >> >> Issues: >> (7) Is the answer to #6 any different when the PLAY request is not >> queued? Hopefully not. >> > > I would argue for case ii without the words immediately transition. As > the > second play happens when no other play is active the media should start > playing > when the request is received by the server. And as it is rangeless and > no pause > was the command prior it starts playing npt=0-. "immediately transition" was an editing error in this case. Why should it start from time 0? Does playing with a closed range not reset the pause point? If so, I was not aware of that. We assumed that after a play with a closed range, the pause point was set to the end of said closed range. [...] > 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. Agreed. > 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 never read the RFC that way, but you may be correct. We should clarify it. Does it make sense for PLAY halting to not sent the pause point? Are other implementations interpreting the RFC this way too? We need to consider the state machine implications of all of this as well. Another scenario I left off is the case where the client sends PLAY request with an open ended range, and then sends a PAUSE request just before the end of the stream, and the network delays it such that the server receives the PAUSE request after the stream has ended. If we considered "PLAY halted" as the same state as "PAUSE succeeded" then this PAUSE request would result in "method not valid in this state". We may need to either allow PAUSE while in the ready state, or actually distinguish the two states. I was leaning towards saying that we should explicitly allow PAUSE while in the ready state, but what you are saying makes it sound like maybe we should differentiate the two states completely. -- Jonathan Sergent / Jonathan.Sergent@Sun.COM / (650)352-6495 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Mon Jan 28 22:47: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 WAA16528 for ; Mon, 28 Jan 2002 22:47: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 WAA21112; Mon, 28 Jan 2002 22:46: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 WAA21070 for ; Mon, 28 Jan 2002 22:46:49 -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 WAA16523 for ; Mon, 28 Jan 2002 22:46:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Mon, 28 Jan 2002 19:45:13 -0800 >Return-Path: Received: from mail.prognet.com [205.219.198.1] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Mon, 28 Jan 2002 19:45:13 -0800 (PST) Received: from bullwinkle.real.com (bullwinkle.real.com [207.188.22.30]) by prognet.com (8.9.2/8.9.0) with ESMTP id TAA15862 for ; Mon, 28 Jan 2002 19:45:04 -0800 (PST) Received: from usw-sf-list1.sourceforge.net ([::ffff:216.136.171.252]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by bullwinkle.real.com with esmtp; Mon, 28 Jan 2002 19:45: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 16VPCg-000887-00 for ; Mon, 28 Jan 2002 19:45: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, 28 Jan 2002 19:45:02 -0800 X-UIDL: b0a59fbd5980c724215d44de814f7233 To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #18 - 12 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-477400 ] Play without range while playing (noreply@sourceforge.net) 2. [ rtspspec-Bugs-448521 ] URLs in Rtp-Info need to be quoted (noreply@sourceforge.net) 3. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response (noreply@sourceforge.net) 4. [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification (noreply@sourceforge.net) 5. [ rtspspec-Bugs-477404 ] Errors in table in chapter 12 (noreply@sourceforge.net) 6. [ rtspspec-Bugs-477403 ] Missing session header in response (noreply@sourceforge.net) 7. [ rtspspec-Bugs-477405 ] Missing in transport ABNF:source (noreply@sourceforge.net) 8. [ rtspspec-Bugs-477408 ] Session ID BNF, correction (noreply@sourceforge.net) 9. [ rtspspec-Bugs-477408 ] Session ID BNF, correction (noreply@sourceforge.net) 10. [ rtspspec-Bugs-477411 ] SDP examples, field order (noreply@sourceforge.net) 11. [ rtspspec-Bugs-477415 ] Transport header example (noreply@sourceforge.net) 12. [ rtspspec-Bugs-477418 ] RTP info BNF error (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 11:46:00 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477400 ] Play without range while playing Bugs item #477400, was opened at 2001-11-01 23:15 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&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 without range while playing Initial Comment: A PLAY request without a Range header is legal. It starts playing a stream from the beginning unless the stream has been paused. If a stream has been paused via PAUSE, stream delivery resumes at the pause point. If a stream is playing, such a PLAY request causes no ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ further action and can be used by the client to test server liveness. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In a response to play without range while playing, what shall the server do with RTP-Info? The RTP-Info is required according to table in the beginning of chapter 12, but my opinion is that it lacks meaning in this case. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:49 Message: Logged In: YES user_id=3796 We should deprecate this use of PLAY, and add a PING method (so that we can explicitly ensure there are no side effects) The nice thing about PING is that we can define it as bidirectional. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477400&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 14:20:36 -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 for DS - Need WG Input 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: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 14:25:45 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response Bugs item #449074, was opened at 2001-08-08 03:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 Category: General Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Rob Lanphier (robla) Summary: RTP Seqnum offset in Pause Play response Initial Comment: While implementing RTSP and RTP, there is a concernt that after Pause, if Play request selects same stream but another random seqnum offset, RTP receiver may incrrectly report packet losses. It is desirable to add a statement in future RTSP spec to require that the Play response use previous seqnum + 1 as seqnum offset if the Play is to resume a paused stream. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:25 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 telecon) Sequence numbers increase per suggestion. Resolution is a clarification of RFC 1889 and not a new requirement. A new issue was raised to clarify concerns regarding "timestamp monotmnically increasing". (See appendix "B" of specification (RTP usage). ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-24 13:25 Message: Logged In: YES user_id=3796 Discussed on Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 08:00 Message: Logged In: YES user_id=3796 We believe that we can only recommend this solution, but not require it. We'll update the draft to reflect this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 --__--__-- Message: 4 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 14:28:58 -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: Fix for DS - Need WG Input 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: 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 --__--__-- Message: 5 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 14:41:35 -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 - Need WG Input 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: 6 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:23:30 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477403 ] Missing session header in response Bugs item #477403, was opened at 2001-11-01 23:20 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Pending Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Rob Lanphier (robla) Summary: Missing session header in response Initial Comment: Page 38 first example: Example missing session header in response. Should not the client respond with what session id the respond relates to, as the request contained one. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 15:23 Message: Logged In: YES user_id=3796 I don't think this is a mistake. The server isn't required to send back a session identifier if the client sends one. It's only required to generate one if the client *doesn't* specify one....and only then in the SETUP message. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:51 Message: Logged In: YES user_id=3796 Whoops...will fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477403&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:27:24 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477405 ] Missing in transport ABNF:source Bugs item #477405, was opened at 2001-11-01 23:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477405&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Missing in transport ABNF:source Initial Comment: Page 59, the "source:" paragrah what is the intention? Is it just missing in the BNF for transport headers? ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 15:27 Message: Logged In: YES user_id=3796 Fixed in CVS ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:54 Message: Logged In: YES user_id=3796 source needs to be added to the BNF. Will fix. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477405&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:29:07 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477408 ] Session ID BNF, correction Bugs item #477408, was opened at 2001-11-01 23:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Session ID BNF, correction Initial Comment: Section 3.4 definition of session-id should it not be: session-id = 8*( ALPHA | DIGIT | safe ) instead of 1*? ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:40 Message: Logged In: YES user_id=3796 Agreed. Fix for next draft ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194 --__--__-- Message: 9 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:29:38 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477408 ] Session ID BNF, correction Bugs item #477408, was opened at 2001-11-01 23:27 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Session ID BNF, correction Initial Comment: Section 3.4 definition of session-id should it not be: session-id = 8*( ALPHA | DIGIT | safe ) instead of 1*? ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 15:29 Message: Logged In: YES user_id=3796 Fixed in CVS ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:40 Message: Logged In: YES user_id=3796 Agreed. Fix for next draft ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477408&group_id=23194 --__--__-- Message: 10 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:46:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477411 ] SDP examples, field order Bugs item #477411, was opened at 2001-11-01 23:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: SDP examples, field order Initial Comment: SDP examples in spec is in wrong order: The SDP specifcation requires a certain order between the type names, see section 6 in RFC 2327. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 15:46 Message: Logged In: YES user_id=3796 I fixed the examples cited. I haven't done a thorough audit of the spec, but I did do a cursory look. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-02 00:48 Message: Logged In: NO Yes. The right sequence is...s->c->t the example seems to be wrong... I can see the mistake at C.3, too ---------------------------------------------------------------------- Comment By: Magnus Westerlund (magwes) Date: 2001-11-01 23:31 Message: Logged In: YES user_id=302620 These are at least erronous 14.4 Live Media Presentation Using Multicast ... m=audio 3456 RTP/AVP 0 a=control:rtsp://live.example.com/concert/audio c=IN IP4 224.2.0.1/16 and C.2 Aggregate Control Not Available ... s=I came from a web page t=0 0 c=IN IP4 0.0.0.0 ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477411&group_id=23194 --__--__-- Message: 11 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 15:51:23 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477415 ] Transport header example Bugs item #477415, was opened at 2001-11-01 23:35 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477415&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Transport header example Initial Comment: Page 68 example with transport header uses which does not include " which the ABNF says it should be. Correct according to ABNF is mode="PLAY" ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 15:51 Message: Logged In: YES user_id=3796 Fixed in CVS ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:47 Message: Logged In: YES user_id=3796 Good point. Needs to be fixed. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477415&group_id=23194 --__--__-- Message: 12 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 16:36:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477418 ] RTP info BNF error Bugs item #477418, was opened at 2001-11-01 23:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: RTP info BNF error Initial Comment: Sec 12.33 RTP info syntax of RTP info is wrong, compared to the example. The current syntax specifec a comma separated list of URLS then follows the parameters. Should it not be like this? RTP-Info = "RTP-Info" ":" 1#rtp-info-spec rtp-info-spec = stream-url 1*parameter stream-url = "url" "=" url parameter = ";" "seq" "=" 1*DIGIT | ";" "rtptime" "=" 1*DIGIT ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 16:36 Message: Logged In: YES user_id=3796 Fixed in CVS ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 09:56 Message: Logged In: YES user_id=3796 Will fix -- may want to couple this with #448521 ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-11-02 01:04 Message: Logged In: NO you are right. spec. must be changed ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477418&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 Jan 29 08:50: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 IAA02986 for ; Tue, 29 Jan 2002 08:50: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 IAA01876; Tue, 29 Jan 2002 08:50: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 IAA01847 for ; Tue, 29 Jan 2002 08:50:06 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02978 for ; Tue, 29 Jan 2002 08:50:01 -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 g0TDo1X4029477; Tue, 29 Jan 2002 14:50:01 +0100 (MET) Received: from era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA09973; Tue, 29 Jan 2002 14:50:01 +0100 Message-ID: <3C56A889.4FE26E91@era.ericsson.se> Date: Tue, 29 Jan 2002 14:50:01 +0100 From: Magnus Westerlund X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Sergent CC: 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 Jonathan, see comments inline. Jonathan Sergent wrote: > On Monday, January 28, 2002, at 01:38 AM, Magnus Westerlund wrote: > > (scenario #2) > >> The question is what the > >> second PLAY request should do. My interpretation of the RFC, as > >> currently written, is that this play should be queued, so that the > >> result is that the server streams the first ten seconds of the audio, > >> immediately transitions, and then streams the first ten seconds of the > >> video. > > > > I don't agree on that interpretation. If you compare this with true > > non-aggregated, i.e. separate rtsp sessions, the second play would be > > done > > immediately and not queued as it is on another media. > > However, these requests are all in the same RTSP session. I don't think > the RFC actually answers my question #3. Can you point me to a section > in the RFC to back up your interpretation? Or can we agree that it is > not specified? I can agree that is not specified. I just made the interpretation that the queue should be for each media and one for the session. Which of course makes thing very complicated and unclear. > > [...] > >> (3) Should there be a queue for each URL used with PLAY, or one > >> queue for each RTSP session? If the queue is per-URL instead of > >> per-session, then it is unclear what do do if the client PAUSEs > >> a different URL than it PLAYed. > [...] > > (Scenario #4) > >> I see similar options to scenario #3. > >> i. Play the first ten seconds of the audio, then immediately > >> transition > >> to the video. The video plays for the range "npt=10-". > >> ii. Play the first ten seconds of the audio, then immediately > >> transition > >> to the video. The video plays for the range "npt=0-". > >> > >> Issues: > >> (7) Is the answer to #6 any different when the PLAY request is not > >> queued? Hopefully not. > >> > > > > I would argue for case ii without the words immediately transition. As > > the > > second play happens when no other play is active the media should start > > playing > > when the request is received by the server. And as it is rangeless and > > no pause > > was the command prior it starts playing npt=0-. > > "immediately transition" was an editing error in this case. Why should > it start from time 0? Does playing with a closed range not reset the > pause point? If so, I was not aware of that. We assumed that after a > play with a closed range, the pause point was set to the end of said > closed range. 10.5 in RFC 2326 A PLAY request without a Range header is legal. It starts playing a stream from the beginning unless the stream has been paused. If a stream has been paused via PAUSE, stream delivery resumes at the pause point. If a stream is playing, such a PLAY request causes no further action and can be used by the client to test server liveness. My interpretation of the above text is that a play without range is only resuming if there has been a PAUSE request as the last play or pause request. Otherwise there exist no pause point to resume from. And if there exist no pause point a play without range starts from the beginning. > > > 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 never read the RFC that way, but you may be correct. We should > clarify it. > Agreed. > > Does it make sense for PLAY halting to not sent the pause point? Are > other implementations interpreting the RFC this way too? I guess you mean set. And I believe both have some functionality justification. But also I would like to hear others interpretation of the RFC in this respect. > > We need to consider the state machine implications of all of this as > well. Another scenario I left off is the case where the client sends > PLAY request with an open ended range, and then sends a PAUSE request > just before the end of the stream, and the network delays it such that > the server receives the PAUSE request after the stream has ended. If we > considered "PLAY halted" as the same state as "PAUSE succeeded" then > this PAUSE request would result in "method not valid in this state". We > may need to either allow PAUSE while in the ready state, or actually > distinguish the two states. I was leaning towards saying that we should > explicitly allow PAUSE while in the ready state, but what you are saying > makes it sound like maybe we should differentiate the two states > completely. As I have pointed out in another bug report the state machine in the appendix is rather incomplete. I think that we need to draw the state machine and all transitions that are possible and be sure that we understand the implications of every on of them. It is very bad that a state machine is so hard to draw in ascii. Cheers Magnus Westerlund Audio Technology, Ericsson Research ---------------------------------------------------------------------- Ericsson Radio Systems AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@era-t.ericsson.se _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 29 12:51: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 MAA11170 for ; Tue, 29 Jan 2002 12:51: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 MAA17647; Tue, 29 Jan 2002 12:50: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 MAA17595 for ; Tue, 29 Jan 2002 12:50:50 -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 MAA11161 for ; Tue, 29 Jan 2002 12:50:47 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g0THojC23763 for ; Tue, 29 Jan 2002 18:50:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jan 29 18:50:43 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jan 2002 18:50:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4CF1B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , iesg@ietf.org Cc: mmusic@ietf.org, ipng@sunroof.eng.sun.com, seancolson@yahoo.com Date: Tue, 29 Jan 2002 18:50:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: Last Call: Support for IPv6 in SDP 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 ' > 2) s/The URI contains an IPv4 compatible IPv6 address/The > URI contains an > IPv4-mapped address/ in the header, or change u=. => I believe this should be 'IPv4-mapped' > > 3) IMO, it's a bit questionable to use IPv4-mapped > addresses like this > anyway. IPv4-mapped addresses should only be used (apart > from e.g. SIIT > definition) as a node's internal representation for IPv4 > address; for > better compatibility, the node should use: > > u=http://10.2.12.126/marsII > => But this does not look like an IPv6 address for an IPv6-only node. The SIIT case you mentioned above is an example where this would not work. > (this way the receiving IPv6 node can decide the mechanism > to reach the > IPv4-address; that is, if u= can contain either IPv4 or > IPv6 address) => The 'network' must give an indication of the mechanism to be used. If you use NAT-PT then you'll always see IPv6 addresses, if you use SIIT then you will see the mapped addresses, which will dictate certain actions by the IPv6-only device. If the device is dual stacked, the network will still give the indication of whether: - IPv4 only is allowed. - IPv6 only are allowed. - Both IP stacks are alowed. This is implicit from, say: - the knowledge you receive from your default router - Whether you can get an address (similar to the point above) and other indications. So the point is, a host can't just decide in isolation about what mechanism has to be used, it needs indications from the network, and that is why presenting the address as a mapped address is needed. Hesham > > Also: > --8<-- > IP6-multicast = hexpart [ ":" IP4-multicast ] > "/" ttl [ "/" integer ] > ; IPv6 address starting with FF00 > --8<-- > > 1) 'ttl' is not defined anywhere? (rather obvious though); > (_TTL_ is not > defined in IPv6 anyway, though.) > > 2) IPv6-multicast address does not need to start with FF00; > anything > beginning with FF is syntactically ok. > > 3) The full list of ABNF notations could be split to "normative" and > "informative" (e.g. of the latter, in this context, > IP4-address, b1, b4, > perhaps others), but that's a matter of opinion/clarity I guess. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 29 13:18: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 NAA12167 for ; Tue, 29 Jan 2002 13: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 NAA19566; Tue, 29 Jan 2002 13:17: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 NAA19533 for ; Tue, 29 Jan 2002 13:17:57 -0500 (EST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12145; Tue, 29 Jan 2002 13:17:53 -0500 (EST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g0TIHOp29528; Tue, 29 Jan 2002 20:17:24 +0200 Date: Tue, 29 Jan 2002 20:17:23 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: iesg@ietf.org, , , In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802D4CF1B@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RE: Last Call: Support for IPv6 in SDP 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 On Tue, 29 Jan 2002, Hesham Soliman (ERA) wrote: > > 3) IMO, it's a bit questionable to use IPv4-mapped > > addresses like this > > anyway. IPv4-mapped addresses should only be used (apart > > from e.g. SIIT > > definition) as a node's internal representation for IPv4 > > address; for > > better compatibility, the node should use: > > > > u=http://10.2.12.126/marsII > > > > => But this does not look like an IPv6 address > for an IPv6-only node. The SIIT case you > mentioned above is an example where this > would not work. See below. > > (this way the receiving IPv6 node can decide the mechanism > > to reach the > > IPv4-address; that is, if u= can contain either IPv4 or > > IPv6 address) I'll restate this: this depends on the definition of u=. If 'u' can have: 1) only IPv6 addresses, using mapped address is fine 2) either iPv6 or IPv4 address, IMO IPv4 should be used when _sending_ the packet We're arguing about point 2). My point is that if address can be either, some nodes [a dual stack] can receive values with u=[ipv4] _anyway_, and must be able to cope with them. > => The 'network' must give an indication > of the mechanism to be used. If you use > NAT-PT then you'll always see IPv6 > addresses, if you use SIIT then you will > see the mapped addresses, which will dictate > certain actions by the IPv6-only device. [snip rest] Yeah, but the draft isn't about what the packet will look like after it has been mangled by NAT-PT or SIIT -- what should be best when sent by some node. It's clear that if an IPv6-only node sees a packet, u= must be an IPv6 address of _some_ form (if it's supposed to be reachable). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Tue Jan 29 21:15: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 VAA26910 for ; Tue, 29 Jan 2002 21:15: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 VAA14258; Tue, 29 Jan 2002 21:13:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14219 for ; Tue, 29 Jan 2002 21:13:39 -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 VAA26863 for ; Tue, 29 Jan 2002 21:13:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) (uid 500) by goobox with local; Tue, 29 Jan 2002 18:12:02 -0800 >Return-Path: Received: from mail.prognet.com [205.219.198.1] by localhost with POP3 (fetchmail-5.9.6) for robla@localhost (single-drop); Tue, 29 Jan 2002 18:12:02 -0800 (PST) Received: from bullwinkle.real.com (bullwinkle.real.com [207.188.22.30]) by prognet.com (8.9.2/8.9.0) with ESMTP id SAA09104 for ; Tue, 29 Jan 2002 18:11:03 -0800 (PST) Received: from usw-sf-list1.sourceforge.net ([::ffff:216.136.171.252]) (TLS: TLSv1/SSLv3,168bits,DES-CBC3-SHA) by bullwinkle.real.com with esmtp; Tue, 29 Jan 2002 18:11:01 -0800 Received: from localhost ([127.0.0.1] helo=usw-sf-list1.sourceforge.net) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 16VkDG-0006K3-00 for ; Tue, 29 Jan 2002 18:11: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: Tue, 29 Jan 2002 18:11:02 -0800 X-UIDL: bb3a82bf45bf7a17160b70296e3ad35d To: mmusic@ietf.org Reply-to: mmusic@ietf.org Content-Transfer-Encoding: 7bit Subject: [MMUSIC] Rtspspec-bugs digest, Vol 1 #19 - 12 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-477420 ] Missing definition of 1\# (noreply@sourceforge.net) 2. [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities (noreply@sourceforge.net) 3. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT (noreply@sourceforge.net) 4. [ rtspspec-Bugs-496932 ] Require: option-tag BNF allows comma (noreply@sourceforge.net) 5. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response (noreply@sourceforge.net) 6. [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response (noreply@sourceforge.net) 7. [ rtspspec-Bugs-500868 ] Require: option-tag values unclear (noreply@sourceforge.net) 8. [ rtspspec-Bugs-461083 ] Body w/o Content-Length clarification (noreply@sourceforge.net) 9. [ rtspspec-Bugs-477407 ] Transport BNF, ; and unclearities (noreply@sourceforge.net) 10. [ rtspspec-Bugs-477413 ] Transport BNF: mode (noreply@sourceforge.net) 11. [ rtspspec-Bugs-477413 ] Transport BNF: mode (noreply@sourceforge.net) 12. [ rtspspec-Bugs-477416 ] BNF error section 3.6 NPT (noreply@sourceforge.net) --__--__-- Message: 1 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 16:40:20 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-477420 ] Missing definition of 1\# Bugs item #477420, was opened at 2001-11-01 23:42 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477420&group_id=23194 Category: None Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Magnus Westerlund (magwes) Assigned to: Nobody/Anonymous (nobody) Summary: Missing definition of 1\# Initial Comment: What is the definition of 1\# in the BNF? I can't find it in either RFC 2068, 2234, 2326, or 2616. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 16:40 Message: Logged In: YES user_id=3796 This was a processing error due to the spec production method we used last time. We probably won't use the same technique this time around. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 19:57 Message: Logged In: YES user_id=3796 Typo that needs to be fixed. It's "1#", as defined in section 2 of RFC 2326 (comma separated list) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=477420&group_id=23194 --__--__-- Message: 2 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 16:46:44 -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: Fix for DS - Need WG Input 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: 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: 3 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 16:49:34 -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: Fix for DS - Need WG Input 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: 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: Mon, 28 Jan 2002 17:11:57 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-496932 ] Require: option-tag BNF allows comma Bugs item #496932, was opened at 2001-12-26 16:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=496932&group_id=23194 Category: General Group: Fix for DS - Typo/Thinko >Status: Closed Resolution: None Priority: 5 Submitted By: Rob Lanphier (robla) Assigned to: Rob Lanphier (robla) Summary: Require: option-tag BNF allows comma Initial Comment: Emailed from Raj Rajan on 12/26 > In rfc-2326 of RTSP in section 12.32, Require = "Require" ":" > 1#option-tag > Issue here is that option-tag should be seperated by "," and as per > option-tag defination it may contaion ",". > option-tag = 1*xchar > xchar = unreserved | reserved | escape > unreserved = alpha | digit | safe | extra > extra = "!" | "*" | "$'$" | "(" | ")" | "," > So, if "," is present in option-tag, how to differentiate which one is > delimiter in require header. --- Option-tag should be token (or whatever the SIP definition is); this needs to be fixed. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 17:11 Message: Logged In: YES user_id=3796 Aligned with SIP (which indeed uses a [mostly] identically defined "token"). The only difference is that RTSP defines the set of illegal characters as "tspecials", while SIP defines them as "separators". ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=496932&group_id=23194 --__--__-- Message: 5 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 17:48:04 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response Bugs item #449074, was opened at 2001-08-08 03:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 Category: General Group: Fix - Discussed/Resolved Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Rob Lanphier (robla) Summary: RTP Seqnum offset in Pause Play response Initial Comment: While implementing RTSP and RTP, there is a concernt that after Pause, if Play request selects same stream but another random seqnum offset, RTP receiver may incrrectly report packet losses. It is desirable to add a statement in future RTSP spec to require that the Play response use previous seqnum + 1 as seqnum offset if the Play is to resume a paused stream. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 17:48 Message: Logged In: YES user_id=3796 This is pretty clear from Appendix B of the current specification. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:25 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 telecon) Sequence numbers increase per suggestion. Resolution is a clarification of RFC 1889 and not a new requirement. A new issue was raised to clarify concerns regarding "timestamp monotmnically increasing". (See appendix "B" of specification (RTP usage). ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-24 13:25 Message: Logged In: YES user_id=3796 Discussed on Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 08:00 Message: Logged In: YES user_id=3796 We believe that we can only recommend this solution, but not require it. We'll update the draft to reflect this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 --__--__-- Message: 6 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 17:48:51 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-449074 ] RTP Seqnum offset in Pause Play response Bugs item #449074, was opened at 2001-08-08 03:49 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 Category: General Group: Fix - Discussed/Resolved >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Rob Lanphier (robla) Summary: RTP Seqnum offset in Pause Play response Initial Comment: While implementing RTSP and RTP, there is a concernt that after Pause, if Play request selects same stream but another random seqnum offset, RTP receiver may incrrectly report packet losses. It is desirable to add a statement in future RTSP spec to require that the Play response use previous seqnum + 1 as seqnum offset if the Play is to resume a paused stream. ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-28 17:48 Message: Logged In: YES user_id=3796 This is pretty clear from Appendix B of the current specification. ---------------------------------------------------------------------- Comment By: David W. Walker (davidwwalker) Date: 2002-01-28 14:25 Message: Logged In: YES user_id=437905 RESOLUTION: (Jan 9, 2002 telecon) Sequence numbers increase per suggestion. Resolution is a clarification of RFC 1889 and not a new requirement. A new issue was raised to clarify concerns regarding "timestamp monotmnically increasing". (See appendix "B" of specification (RTP usage). ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2002-01-24 13:25 Message: Logged In: YES user_id=3796 Discussed on Jan 9 telecon: http://rtsp.org/2002/telecon/jan09.html RESOLVED: sequence numbers increase per suggestion in report. This is a clarification of RFC 1889, not new requirement ---------------------------------------------------------------------- Comment By: Rob Lanphier (robla) Date: 2001-12-13 08:00 Message: Logged In: YES user_id=3796 We believe that we can only recommend this solution, but not require it. We'll update the draft to reflect this. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=449074&group_id=23194 --__--__-- Message: 7 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Mon, 28 Jan 2002 19:26:09 -0800 Subject: [rtspspec-bugs] [ rtspspec-Bugs-500868 ] Require: option-tag values unclear Bugs item #500868, was opened at 2002-01-08 08:09 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194 Category: None >Group: Fix for DS - Need WG Input Status: Open Resolution: None Priority: 5 Submitted By: Sean Sheedy (seansh) Assigned to: Nobody/Anonymous (nobody) Summary: Require: option-tag values unclear Initial Comment: The proper option-tag values to use in the Require: header when checking for optional features are not always clear. Some are more easily guessed then others. For example, to ask whether a server supports the Scale: header, I would guess that the proper option-tag would be "scale". However, how does a client ask whether the server supports the smpte time format in the Range: header? The document should include a table of optional features and their corresponding option-tag values. ---------------------------------------------------------------------- >Comment By: Rob Lanphier (robla) Date: 2002-01-28 19:26 Message: Logged In: YES user_id=3796 This should probably be a separately defined document. The Require header was intended as a way of querying for features outside of the scope of RTSP, rather than for features in RTSP. It is too late to require that existing implementations support new feature tags, but I agree it would be useful thing to have around. A candidate list may fall out of the list of features in RTSP. Sean, would you mind taking a first crack at creating the list of features tags you'd like to see? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=377744&aid=500868&group_id=23194 --__--__-- Message: 8 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 17:56:38 -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: Fix - Discussed/Resolved 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: 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 --__--__-- Message: 9 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 18:03:17 -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: Fix - Discussed/Resolved 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: 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: 10 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 18:06:07 -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: Fix for DS - Need WG Input 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-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: 11 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 18:06: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: Fix - Discussed/Resolved 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-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: 12 To: noreply@sourceforge.net From: noreply@sourceforge.net Date: Tue, 29 Jan 2002 18:08:02 -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: Fix - Discussed/Resolved 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: 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 End of Rtspspec-bugs Digest _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 03:09: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 DAA21712 for ; Thu, 31 Jan 2002 03:09: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 DAA00450; Thu, 31 Jan 2002 03:05:56 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA00419 for ; Thu, 31 Jan 2002 03:05:54 -0500 (EST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21547 for ; Thu, 31 Jan 2002 03:05:50 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g0V85qX4028671 for ; Thu, 31 Jan 2002 09:05:52 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jan 31 09:05:50 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Jan 2002 09:05:50 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802D4D0DD@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Pekka Savola , "Hesham Soliman (ERA)" Cc: iesg@ietf.org, mmusic@ietf.org, ipng@sunroof.eng.sun.com, seancolson@yahoo.com Date: Thu, 31 Jan 2002 09:05:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [MMUSIC] RE: Last Call: Support for IPv6 in SDP 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 I think Gonzalo already answered this. Further clarifications are below, but we might be getting off-topic for this draft. > (this way the receiving IPv6 node can decide the mechanism > > > to reach the > > > IPv4-address; that is, if u= can contain either IPv4 or > > > IPv6 address) > > I'll restate this: this depends on the definition of u=. > > If 'u' can have: > 1) only IPv6 addresses, using mapped address is fine > 2) either iPv6 or IPv4 address, IMO IPv4 should be used > when _sending_ > the packet => See below. > > We're arguing about point 2). My point is that if address > can be either, > some nodes [a dual stack] can receive values with u=[ipv4] > _anyway_, and > must be able to cope with them. => I was not conerned about dual stacked nodes, they'll obviously understand. Some systems require IPv6 only though, Others might prefer to run IPv6 only for simplicity, so you shouldn't assume dual stacks all the time. Hesham _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 07:01: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 HAA24052 for ; Thu, 31 Jan 2002 07:01: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 HAA11357; Thu, 31 Jan 2002 07:01: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 HAA11321 for ; Thu, 31 Jan 2002 07:01: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 HAA24001; Thu, 31 Jan 2002 07:00:57 -0500 (EST) Message-Id: <200201311200.HAA24001@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, 31 Jan 2002 07:00:57 -0500 Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-kmgmt-ext-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 : Key Management Extensions for SDP and RTSP Author(s) : J. Arkko et al. Filename : draft-ietf-mmusic-kmgmt-ext-01.txt Pages : 10 Date : 30-Jan-02 This document defines extensions for SDP and RTSP to carry the security information needed by a key management protocol, in order to secure the media stream. Indications are also given on how it should be used together with SIP and RTSP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-kmgmt-ext-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-kmgmt-ext-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-kmgmt-ext-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: <20020130112953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mmusic-kmgmt-ext-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mmusic-kmgmt-ext-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020130112953.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 Jan 31 13:05: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 NAA06093 for ; Thu, 31 Jan 2002 13:05: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 NAA10879; Thu, 31 Jan 2002 13:03: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 NAA10837 for ; Thu, 31 Jan 2002 13:03:36 -0500 (EST) Received: from mail3.dynamicsoft.com ([63.113.44.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06043; Thu, 31 Jan 2002 13:03:33 -0500 (EST) Received: from dynamicsoft.com ([63.113.46.67]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id g0VI3D6Y009160; Thu, 31 Jan 2002 13:03:13 -0500 (EST) Message-ID: <3C5986B7.8DB8FF31@dynamicsoft.com> Date: Thu, 31 Jan 2002 13:02:31 -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, sip-implementors@cs.columbia.edu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MMUSIC] 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 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 _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 13:11: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 NAA06340 for ; Thu, 31 Jan 2002 13:11: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 NAA11181; Thu, 31 Jan 2002 13:11: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 NAA11146 for ; Thu, 31 Jan 2002 13:11:33 -0500 (EST) Received: from ascomax.hasler.ascom.ch (ascomax.hasler.ascom.ch [139.79.135.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06306 for ; Thu, 31 Jan 2002 13:11:29 -0500 (EST) Received: from stva195.pbx.ascom.ch (stva195-35.pbx.ascom.ch [139.79.35.5]) by ascomax.hasler.ascom.ch (8.11.4/8.11.4) with ESMTP id g0VIBSr12784 for ; Thu, 31 Jan 2002 19:11:28 +0100 (MET) Received: from ascom.ch (localhost [127.0.0.1]) by stva195.pbx.ascom.ch (8.12.1/8.12.1) with ESMTP id g0VIBRNF025964 for ; Thu, 31 Jan 2002 19:11:27 +0100 (MET) Message-ID: <3C5988CE.BA55E22E@ascom.ch> Date: Thu, 31 Jan 2002 19:11:26 +0100 From: Jayakrishnan Prabhakaran Organization: http://www.ascom.com X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mmusic@ietf.org Content-Type: multipart/mixed; boundary="------------EB82ABFBFCC48E9AABE1EF7E" X-Filter-Version: 1.6 (ascomax) 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 This is a multi-part message in MIME format. --------------EB82ABFBFCC48E9AABE1EF7E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit subscribe --------------EB82ABFBFCC48E9AABE1EF7E Content-Type: text/x-vcard; charset=iso-8859-1; name="Jayakrishnan.Prabhakaran.vcf" Content-Description: Card for Jayakrishnan Prabhakaran Content-Disposition: attachment; filename="Jayakrishnan.Prabhakaran.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgCm46UHJhYmhha2FyYW47SmF5YWtyaXNobmFuCnRlbDtjZWxsOis0MSAo MDc5KSAyNTggMzggNzMKdGVsO2ZheDorNDEgKDAzMikgNjI0IDMxIDU2CnRlbDtob21lOis0 MSAoMDMyKSA2NTMgNDEgOTQKdGVsO3dvcms6KzQxICgwMzIpIDYyNCAzMSA5NAp4LW1vemls bGEtaHRtbDpUUlVFCnVybDpodHRwOi8vd3d3LmFzY29tLmNvbQpvcmc6QXNjb20gQUc7RW50 ZXJwcmlzZSBDb21tdW5pY2F0aW9ucyBSJkQKYWRyOjs7WmllZ2VsbWF0dHN0cmFzc2UgMTs0 NTAzLCBTb2xvdGh1cm47OztTd2l0emVybGFuZAp2ZXJzaW9uOjIuMQplbWFpbDtpbnRlcm5l dDpKYXlha3Jpc2huYW4uUHJhYmhha2FyYW5AYXNjb20uY2gKdGl0bGU6U29mdHdhcmUgRW5n aW5lZXIKeC1tb3ppbGxhLWNwdDo7NTA0OApmbjpKYXlha3Jpc2huYW4gUHJhYmhha2FyYW4g CmVuZDp2Y2FyZAo= --------------EB82ABFBFCC48E9AABE1EF7E-- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 15:05: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 PAA10513 for ; Thu, 31 Jan 2002 15:05: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 PAA20620; Thu, 31 Jan 2002 15:05: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 PAA20587 for ; Thu, 31 Jan 2002 15:05:18 -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 PAA10494; Thu, 31 Jan 2002 15:05:12 -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 g0VK5Ch04108; Thu, 31 Jan 2002 14:05:12 -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 g0VK5CX09785; Thu, 31 Jan 2002 14:05:12 -0600 (CST) Received: from lmf.ericsson.se (rmt160168.am.ericsson.se [138.85.160.168]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA21661; Thu, 31 Jan 2002 14:05:08 -0600 (CST) Message-ID: <3C59AA98.AEA5FAE5@lmf.ericsson.se> Date: Thu, 31 Jan 2002 22:35:36 +0200 From: Gonzalo Camarillo X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: Pekka Savola , iesg@ietf.org, mmusic@ietf.org, 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> 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, The draft defines how to express IPv6 addresses in SDP. How you use this format is up to the application (i.e., outside the scope of this draft). Remember that SDP is used by many protocols (SIP, SAP, MGCP, RTSP). A good example is SIP. An MMUSIC document defines how to use SDP in conjunction with SIP. 3G systems, for instance, will use SDP and IPv6 together. They will define how to use this format when establishing a session. They will explicitly say which address you have to put in the c line (IPv4, or IPv6 or maybe FQDN). 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. Regards, Gonzalo "Hesham Soliman (ERA)" wrote: > > I think Gonzalo already answered this. > Further clarifications are below, but > we might be getting off-topic for this draft. > > > (this way the receiving IPv6 node can decide the mechanism > > > > to reach the > > > > IPv4-address; that is, if u= can contain either IPv4 or > > > > IPv6 address) > > > > I'll restate this: this depends on the definition of u=. > > > > If 'u' can have: > > 1) only IPv6 addresses, using mapped address is fine > > 2) either iPv6 or IPv4 address, IMO IPv4 should be used > > when _sending_ > > the packet > > => See below. > > > > > We're arguing about point 2). My point is that if address > > can be either, > > some nodes [a dual stack] can receive values with u=[ipv4] > > _anyway_, and > > must be able to cope with them. > > => I was not conerned about dual stacked nodes, > they'll obviously understand. Some systems > require IPv6 only though, Others might prefer > to run IPv6 only for simplicity, so you shouldn't > assume dual stacks all the time. > > Hesham > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic -- 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 Thu Jan 31 21:40: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 VAA18994 for ; Thu, 31 Jan 2002 21:40: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 VAA08467; Thu, 31 Jan 2002 21:40: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 VAA08430 for ; Thu, 31 Jan 2002 21:40:36 -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 VAA18991 for ; Thu, 31 Jan 2002 21:40:32 -0500 (EST) SUBJECT: Re: [MMUSIC] updated offer/answer draft DATE: 01 Feb 2002 02:40:33 GMT RECEIVED: from WebBizLogic4 by Dispatcher; 1 Feb 2002 02:40:34 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 VAA08431 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 sendrecive 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 Thu Jan 31 22:30: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 WAA19611 for ; Thu, 31 Jan 2002 22:29: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 WAA10069; Thu, 31 Jan 2002 22:29: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 WAA10036 for ; Thu, 31 Jan 2002 22:29:43 -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 WAA19608 for ; Thu, 31 Jan 2002 22:29:38 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 31 Jan 2002 19:29:10 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id TAA23585 for ; Thu, 31 Jan 2002 19:29:10 -0800 (PST) Date: Thu, 31 Jan 2002 19:30:07 -0800 (Pacific Standard Time) From: Rob Lanphier To: "mmusic@ietf.org" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: When to send response (477421) 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 first of many emails regarding the resolutions on the RTSP telecon of Jan 23. From the bug report (http://rtsp.org/bug477421): > 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. * RESOLVED: The server is allowed to send immediate response with no sequence number. However, the server should NOT set the sequence number on behalf of the client. Rob Raw notes below: > 477421 When to send response > > [11]477421 > * JS: may be more of a problem with TCP > * RL: semantically correct should not disconnect, but syntax can > cause disconnect > * SS: should respond with seqnum-less response > * JS: had to fix "bug" on our implementation on this when we blew > away connection > * MW: higher version number response > * JS: should respond with good response > * JS: what should be res on 421 > * JA: send response with no seqnum > * AK: question of when > * JA: huge implementation issue to enforce order > * JA: corner case not worth handling well > * AK: should respond immediately? > * JA: yes...at least not required to respond in request order. > * AK: leave as implementation issue > * JS: agreed > * RL: has anyone implemented RTSP over UDP? > * SS: Yes, implemented RTSP over UDP > * RESOLVED: server allowed to send immediate response with no > sequence number. server should NOT set sequence number _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 22:38: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 WAA20615 for ; Thu, 31 Jan 2002 22:38: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 WAA10697; Thu, 31 Jan 2002 22:37: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 WAA10662 for ; Thu, 31 Jan 2002 22:37:50 -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 WAA20606 for ; Thu, 31 Jan 2002 22:37:45 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 31 Jan 2002 19:37:18 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id TAA25384 for ; Thu, 31 Jan 2002 19:37:18 -0800 (PST) Date: Thu, 31 Jan 2002 19:38:15 -0800 (Pacific Standard Time) From: Rob Lanphier To: "mmusic@ietf.org" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MMUSIC] RTSP: Unclearities regarding pause with range (477423) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org From the bug report (http://rtsp.org/bug477423) > 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. (further notes) > Does need clarification in specification, but probably warrents > discussion. > > Recommendation: end time in range is ignored This issue was discussed further on the list: http://www1.ietf.org/mail-archive/working-groups/mmusic/current/msg00102.html * 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 ---- Raw notes. > 477423 Unclearities regarding pause with range > > [12]477423 > > * MB: pause with range gives you a "loose" range > * JS: is that useful? > * MB: if the time for the pause is already past? > * JS: should avoid changing semantics > * MW: what about UTC? > * JS: I don't think you can specify UTC > * JS: anyone implement UTC stuff > * RL: not us > * AJ: not us > * MW: we have > * JS: you may be only one. We need to forbid mixing > * SS: we implemented > * MW: we can remove this for pause > * JS: you could want to use with nothing but UTC Revised: * 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. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 22:44: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 WAA20841 for ; Thu, 31 Jan 2002 22:44: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 WAA10904; Thu, 31 Jan 2002 22: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 WAA10871 for ; Thu, 31 Jan 2002 22:44:05 -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 WAA20837 for ; Thu, 31 Jan 2002 22:44:00 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 31 Jan 2002 19:43:33 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id TAA26580 for ; Thu, 31 Jan 2002 19:43:29 -0800 (PST) Date: Thu, 31 Jan 2002 19:44:25 -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: Inconsistency between timeformats (477425) Sender: mmusic-admin@ietf.org Errors-To: mmusic-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Multiparty Multimedia Session Control Working Group X-BeenThere: mmusic@ietf.org From the bug (http://rtsp.org/bug477425) > NPT time in range is allowed to be specifed as "-nptime". No other > timeformat allows that, why? We're pretty sure this is a thinko, and we think that this technique should be extended to the other time formats. * RESOLVED: Extend this to other time formats, and probably clarify the semantics of this particular syntax. Should start at pause point or the beginning. Rob Raw notes: > * JS: agree with note in 477425 > * RESOLVED: Extend this to other time formats, and probably clarify > the semantics of this particular syntax. Should start at pause point or > the beginning. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic From mmusic-admin@ietf.org Thu Jan 31 22:51: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 WAA20908 for ; Thu, 31 Jan 2002 22:51: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 WAA11099; Thu, 31 Jan 2002 22:51: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 WAA11068 for ; Thu, 31 Jan 2002 22:51:20 -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 WAA20893 for ; Thu, 31 Jan 2002 22:51:15 -0500 (EST) Received: from prognet.com ([::ffff:205.219.198.1]) by bullwinkle.real.com with esmtp; Thu, 31 Jan 2002 19:50:48 -0800 Received: from ROBLA350 ([172.23.100.116]) by prognet.com (8.9.2/8.9.0) with ESMTP id TAA28098 for ; Thu, 31 Jan 2002 19:50:49 -0800 (PST) Date: Thu, 31 Jan 2002 19:51:45 -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: Transport model requirements (477427) 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 more involved issue. From the bug (http://rtsp.org/bug477427): > Which connection models are required. Is non persitent TCP connections a > MUST support, or only RECOMMENDED? * RESOLVED: Default is connection-oriented (thus, required), and connectionless MAY be implemented. We need to define header and response for non-persistent connections. Look into "Supported" header in SIP. We still haven't entirely resolved this issue. Is the "Supported" header the right model to use? Rob ----- Raw notes: 477427 * JS: We close things down, but we'd like to fix that * RL: how does liveness indication work * JS: we use RTCP * JS: Darwin hangs up if RTCP isn't received. * AJ: Correct. Some firewalls don't work well with this. * MW: There's a PING method request * TM: security issues with connectionless * JS: ssl is the way to solve this if that's a big issue * MW: what about original issue? * JS: needs to be negotiable option * MW: Use spec terminology: "persistent" and "non-persistent" * JS: Pragma specifically removed. * AK: perhaps "Supported" should be used * RESOLVED: define header and response for non-persistent connections. Default is connection-oriented, and connectionless MAY be implemented. Look into "supported" header. _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic